Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Easier Custom Authentication errors #15882

Merged
merged 1 commit into from Sep 28, 2015

Conversation

weaverryan
Copy link
Member

Q A
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets n/a
License MIT
Doc PR not yet

This makes failing authentication with a custom message much easier:

throw CustomAuthenticationException::createWithSafeMessage(
    'That was a ridiculous username'
);

// or
$e = new CustomAuthenticationException();
$e->setSafeMessage('That was a ridiculous username');

throw $e;

Currently, to do this, you'd need to create a new sub-class of AuthenticationException, which is way more work than it needs to be. The original design was so that all messages exposed are safe, which is why I've named the methods like I have.

Thanks!

*
* @author Ryan Weaver <ryan@knpuniversity.com>
*/
class CustomAuthenticationException extends AuthenticationException
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would convey the "safe" (not sure if safe is the right word here) notion in the class name.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose that safe here means: can be displayed to the end user.

@weaverryan weaverryan force-pushed the custom-authentication-exception branch from 1773c01 to 556abe0 Compare September 26, 2015 15:44
@weaverryan
Copy link
Member Author

I've just made all the suggested changes. To avoid having the static method call, I've made the $message constructor be the safe message. I think this is still safe because I've renamed the class to highlight that you're passing in a safe message. We could not override the constructor and force the setter to be called to - it's just a little less convenient.

*/

namespace Symfony\Component\Security\Core\Exception;
use Exception;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be inlined as a FQCN

@wouterj
Copy link
Member

wouterj commented Sep 26, 2015

Status: Needs work

@weaverryan
Copy link
Member Author

Updated!

Status: Needs Review


if ('' !== $message) {
$this->messageKey = $message;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, no you removed the complete method call. In such cases, the Symfony standard is to remove any pre-configured defaults in the property definition and just call $this->messageKey = $message; $this->messageData = $messageData;

@weaverryan weaverryan force-pushed the custom-authentication-exception branch from d616938 to 84dd924 Compare September 26, 2015 17:01
@weaverryan
Copy link
Member Author

@wouterj check it out now - I just simplified things - I think this makes more sense.

*
* @author Ryan Weaver <ryan@knpuniversity.com>
*/
class SafeMessageAuthenticationException extends AuthenticationException
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really not comfortable with the naming. The idea is that the message is safe to be displayed to the end user. So, what about UserMessageAuthenticationException, or UserFacingAuthenticationException, UserOrientedAuthenticationException? You get my point; the naming should indicate that the message is "for end users". My proposals are probably not the right ones, but we need to find a better name.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More proposals: PublicAuthenticationException, ExposedAuthenticationException, VisibleAuthenticationException

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just tried CustomUserMessageAuthenticationException. It's the the longest of all ideas, but it's clear to me: this is how you show a custom message... to your user. Leanna liked it better than UserFacingMessageAuthenticationException, fwiw ;)

@weaverryan weaverryan force-pushed the custom-authentication-exception branch 2 times, most recently from 2d16ab0 to af25c3b Compare September 27, 2015 20:39
@weaverryan weaverryan force-pushed the custom-authentication-exception branch from af25c3b to d7c1463 Compare September 27, 2015 20:39
@fabpot
Copy link
Member

fabpot commented Sep 28, 2015

Thank you @weaverryan.

@fabpot fabpot merged commit d7c1463 into symfony:2.8 Sep 28, 2015
fabpot added a commit that referenced this pull request Sep 28, 2015
This PR was merged into the 2.8 branch.

Discussion
----------

Easier Custom Authentication errors

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | n/a
| License       | MIT
| Doc PR        | not yet

This makes failing authentication with a custom message much easier:

```php
throw CustomAuthenticationException::createWithSafeMessage(
    'That was a ridiculous username'
);

// or
$e = new CustomAuthenticationException();
$e->setSafeMessage('That was a ridiculous username');

throw $e;
```

Currently, to do this, you'd need to create a new sub-class of `AuthenticationException`, which is way more work than it needs to be. The original design was so that all messages exposed are safe, which is why I've named the methods like I have.

Thanks!

Commits
-------

d7c1463 Adding a class to make it easier to set custom authentication error messages
@fabpot fabpot mentioned this pull request Nov 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants