Since the member section ID is typically set in the frontend form (using a hidden field), a (malicious) user can easily manipulate it. Of course, "evil" section IDs like %3Benv should not result in anything useful, and they don't, as far as I see.
But I suggest to remove the exception that is thrown if setting the ID fails. If somebody manipulates the section ID in a bad way, the function returns false, and there is no need to disclose any information about what went wrong in this case. In other words: The user shouldn't be able to trigger such an exception so easily, I prefer a "silent fail".
I will send a PR. I know that this can be discussed or even rejected.
Since the member section ID is typically set in the frontend form (using a hidden field), a (malicious) user can easily manipulate it. Of course, "evil" section IDs like
%3Benvshould not result in anything useful, and they don't, as far as I see.But I suggest to remove the exception that is thrown if setting the ID fails. If somebody manipulates the section ID in a bad way, the function returns false, and there is no need to disclose any information about what went wrong in this case. In other words: The user shouldn't be able to trigger such an exception so easily, I prefer a "silent fail".
I will send a PR. I know that this can be discussed or even rejected.