How to handle exceptions when using @Authenticate

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

How to handle exceptions when using @Authenticate

Andreas Joseph Krogh-2
Hi.
 
I'm using Spring to authenticate in a controller-method marked with @Authenticate and Spring might throw org.springframework.security.authentication.LockedException
 
What is the correct way to handle this? Should I catch it and re-throw NotAuthorizedException?
 
Thanks.
 
--
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963

_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: How to handle exceptions when using @Authenticate

Andreas Joseph Krogh-2
På tirsdag 19. april 2016 kl. 09:32:22, skrev Andreas Joseph Krogh <[hidden email]>:
Hi.
 
I'm using Spring to authenticate in a controller-method marked with @Authenticate and Spring might throw org.springframework.security.authentication.LockedException
 
What is the correct way to handle this? Should I catch it and re-throw NotAuthorizedException?
 
Thanks.
 
Anyone?
 
--
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
 

_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: How to handle exceptions when using @Authenticate

bradmacnz
Yes, probably. Note that a not auth exception will mean the end user is prompted to enter their credentials again, I'm not sure if thats what you want, because i guess attempting to login again wont work. It might possibly be better to throw a  BadRequestException which should mean the user is given an error but not prompted to login again.

On 24/05/16 08:45, Andreas Joseph Krogh wrote:
På tirsdag 19. april 2016 kl. 09:32:22, skrev Andreas Joseph Krogh <[hidden email]>:
Hi.
 
I'm using Spring to authenticate in a controller-method marked with @Authenticate and Spring might throw org.springframework.security.authentication.LockedException
 
What is the correct way to handle this? Should I catch it and re-throw NotAuthorizedException?
 
Thanks.
 
Anyone?
 
--
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
 


_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users


_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: How to handle exceptions when using @Authenticate

Andreas Joseph Krogh-2
På onsdag 25. mai 2016 kl. 01:25:01, skrev Brad McEvoy <[hidden email]>:
Yes, probably. Note that a not auth exception will mean the end user is prompted to enter their credentials again, I'm not sure if thats what you want, because i guess attempting to login again wont work. It might possibly be better to throw a  BadRequestException which should mean the user is given an error but not prompted to login again.
 
Why is that the semantics of NotAuth? NotAuth is not the same as BadCredentials. It is true that attempting to login again won't work and I'm looking for a way to express "Ok, you don't have access (not-auth), no need to try again", without cluttering the logs with stack-traces (as StandardFilter.process seems to do).
 
My point is that a user which is locked out or disabled or which cannot login for whatever reason, other than BadCredentials, is not "exceptional" in the sense that an exception should be logged.
 
--
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
 

_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: How to handle exceptions when using @Authenticate

bradmacnz
What i mean is that if spring throws a locked exception, then presumably that means the user will not be able to successfully login if they try again. If that is the case, then you probably dont want them prompted to login again.

That should be reported as a 403 Forbidden. From the spec:
401 Unauthorized (RFC 7235)Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided.
403 Forbidden
The request was a valid request, but the server is refusing to respond to it. 403 error semantically means "unauthorized", i.e. the user does not have the necessary permissions for the resource.



And milton does report a 403 when authentication succeeded but authorisation failed:

    public void respondUnauthorised(Resource resource, Response response, Request request) {
        if (authenticationService.canUseExternalAuth(resource, request)) {
            log.info("respondUnauthorised: use external authentication");
            initiateExternalAuth(resource, request, response);
        } else {
            Auth auth = request.getAuthorization();
            if (auth == null || auth.getTag() == null) {
                log.info("respondUnauthorised: no authenticated user, so return status: " + Response.Status.SC_UNAUTHORIZED);
                response.setStatus(Response.Status.SC_UNAUTHORIZED);
                List<String> challenges = authenticationService.getChallenges(resource, request);
                response.setAuthenticateHeader(challenges);

            } else {
                log.info("respondUnauthorised: request has an authenticated user, so return status: " + Response.Status.SC_FORBIDDEN);
                response.setStatus(Response.Status.SC_FORBIDDEN);

            }
        }
    }


However, most clients treat 401 and 403 identically. So to avoid re-prompting for login it us usually necessary to respond with a 400 Bad Request

Regarding the stack trace, best thing is to suppress that with your logging configuration (only a 1 line change to log4j.properties)

Its true that an authorisation failure is not semantically exceptional, and you do not need to throw an exception (although spring is anyway..). Rather then throw an exception you can return an appropriate lack of priviledges from your @AccessControlList method if using annotations, or return false from authorise if using the Resource API


On 27/05/16 09:16, Andreas Joseph Krogh wrote:
På onsdag 25. mai 2016 kl. 01:25:01, skrev Brad McEvoy <[hidden email]>:
Yes, probably. Note that a not auth exception will mean the end user is prompted to enter their credentials again, I'm not sure if thats what you want, because i guess attempting to login again wont work. It might possibly be better to throw a  BadRequestException which should mean the user is given an error but not prompted to login again.
 
Why is that the semantics of NotAuth? NotAuth is not the same as BadCredentials. It is true that attempting to login again won't work and I'm looking for a way to express "Ok, you don't have access (not-auth), no need to try again", without cluttering the logs with stack-traces (as StandardFilter.process seems to do).
 
My point is that a user which is locked out or disabled or which cannot login for whatever reason, other than BadCredentials, is not "exceptional" in the sense that an exception should be logged.
 
--
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
 


_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users


_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: How to handle exceptions when using @Authenticate

Andreas Joseph Krogh-2
På torsdag 26. mai 2016 kl. 23:47:16, skrev Brad McEvoy <[hidden email]>:
What i mean is that if spring throws a locked exception, then presumably that means the user will not be able to successfully login if they try again. If that is the case, then you probably dont want them prompted to login again.

That should be reported as a 403 Forbidden. From the spec:
[snip]
However, most clients treat 401 and 403 identically. So to avoid re-prompting for login it us usually necessary to respond with a 400 Bad Request
 
That's a bummer, it means we cannot reliably differentiate between BadCredentials and NotAuthorized, correct?
 
Regarding the stack trace, best thing is to suppress that with your logging configuration (only a 1 line change to log4j.properties)
 
The problem with this approach is that it will hide real BadRequestExceptions, which I want to log with stacktrace.
 
Its true that an authorisation failure is not semantically exceptional, and you do not need to throw an exception (although spring is anyway..). Rather then throw an exception you can return an appropriate lack of priviledges from your @AccessControlList method if using annotations, or return false from authorise if using the Resource API
 
The problem is that the @Authenticate method returns Boolean so I don't have a way to bring information about "Not authorized" on to the
@AccessControlList methods, without making my User objects mutable, which I'd rather not. My real app is a Scala-app where all Dav-objects (the DTOs I use with Milton) are immutable
 
--
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
 

_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users