UnauthorizedException => UnauthenticatedException

[dereuromark]

There was a small discussion around it here
#191 (comment)

But if you only use this plugin and either you are logged in (authenticated) or not, then it must clearly be UnauthenticatedException - as at this point it does not even know about the concept of authorization and role management etc.

So would you be OK with renaming the exception here inside of this plugin at this state?
To make things consistent and a bit more clear from the naming (as there are now also two different plugins).

[markstory]

My only concern with renaming is that the exception name will no longer match the http status code description. I can let go of that though.

[dereuromark]

The 401? Yeah, but that is part of the http specs problem, not ours IMO.
As per https://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses

There's a problem with 401 Unauthorized, the HTTP status code for authentication errors. And that’s just it: it’s for authentication, not authorization. Receiving a 401 response is the server telling you, “you aren’t authenticated–either not authenticated at all or authenticated incorrectly–but please reauthenticate and try again.” To help you out, it will always include a WWW-Authenticate header that describes how to authenticate.
This is a response generally returned by your web server, not your web application.
It’s also something very temporary; the server is asking you to try again.
So, for authorization I use the 403 Forbidden response. It’s permanent, it’s tied to my application logic, and it’s a more concrete response than a 401.
Receiving a 403 response is the server telling you, “I’m sorry. I know who you are–I believe who you say you are–but you just don’t have permission to access this resource. Maybe if you ask the system administrator nicely, you’ll get permission. But please don’t bother me again until your predicament changes.”
In summary, a 401 Unauthorized response should be used for missing or bad authentication, and a 403 Forbidden response should be used afterwards, when the user is authenticated but isn’t authorized to perform the requested operation on the given resource.

From the plugin's perspective it might just be a bit cleaner to use our "proper" naming conventions here, and the status code is just a low level implementation detail along the way.

[dereuromark]

Resolved with #209

[inoas]

So will we use UnauthorizedException with HTTP 403 and UnauthenticatedException with HTTP 401 (aka both exceptions should exist)?

Edit: Yes what I meant is both should exist as part of CakePHPs exceptions / HTTP client

[dereuromark]

UnauthorizedException is not part of this plugin - obviously.
As explained there can only be either not logged in or logged in - the authorization part is part of the other plugin.