Add interceptor to catch 401 responses, hold http requests until user has been authenticated.

[lynndylanhurley]

Add interceptor to catch 401 responses, hold http requests until user has been authenticated.

[dehru]

This is a nice package that I have used on 2 products that solves this for you.

https://github.com/witoldsz/angular-http-auth

[lynndylanhurley]

Thanks @dehru! I'll look into this asap.

[Urigo]

You can also look at this implementation and just copy it (look at the 'AuthInterceptor' factory in the security.js file):
https://github.com/asafdav/ng-secure

[lynndylanhurley]

Wow thanks! I need to get some test coverage in place before I add this
feature, but thank you for these great resources. Hopefully I'll be able to
tackle this within the next few days.
On Jul 9, 2014 12:42 PM, "Uri Goldshtein" [email protected] wrote:

You can also look at this implementation and just copy it (look at the
'AuthInterceptor' factory in the security.js file):
https://github.com/asafdav/ng-secure

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[stryju]

@dehru 's link would be the way to go, but it has one caveat (which i'll be working on):
it will still fire the rest of the requests and THEN it will put them into "retry" queue - better way would be to put them in the queue BEFORE firing potential 401 responses

other than this - it works great :-)

[lynndylanhurley]

We will also need to consider:

• is the request directed to our api? A 401 from another endpoint could
  trigger a false flag.
• are there any promises waiting on the requests to resolve? Queuing
  requests could complicate promise resolution.
  On Jul 22, 2014 3:58 AM, "tomasz stryjewski" [email protected]
  wrote:

@dehru https://github.com/dehru 's link would be the way to go, but it
has one caveat (which i'll be working on):
it will still fire the rest of the requests and THEN it will put them into
"retry" queue - better way would be to put them in the queue BEFORE firing
potential 401 responses

other than this - it works great :-)

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[stryju]

@lynndylanhurley

• are there any promises waiting on the requests to resolve? Queuing requests could complicate promise resolution.

no, not really - the way it's solved @ https://github.com/witoldsz/angular-http-auth works great, but with the caveat i described - the http request itself is a promise - just don't pass it along and retry when it makes sense (after auth?)

• is the request directed to our api? A 401 from another endpoint could
  trigger a false flag.

shouldn't #3 fix just that? ;-)

[lynndylanhurley]

is the request directed to our api? A 401 from another endpoint could trigger a false flag.

shouldn't #3 fix just that? ;-)

Yes! I think so.

the http request itself is a promise - just don't pass it along and retry when it makes sense (after auth?)

I mean that it may complicate things in the user space. Consider the following sequence of events:

1. the user tries to access a restricted page. access to the page is contingent on the resolution of a restricted api request
2. the request returns a 401 response
3. the request is queued
4. the user is redirected to login page
5. the user, without logging in, tries to access a different restricted page. this page initiates two restricted api calls (like a batch request)
6. the requests are queued (now 3 requests in the queue)
7. the user is redirected to the login page
8. the user logs in

At this point, which request(s) should resolve?

• not all of them, because it's no longer clear which page the user wants to visit.
• not just the last item in the queue, because that would only be 1/2 of the batch request

We will need to:

1. allow for queue invalidation
2. determine if it's possible to manage the queue automatically. I think that it is possible, but it will require some thought.

I'm working this out now, I hope to have a solution within the next few days.

[dehru]

Maybe I'm not thinking hard enough about this, but as soon as you get a 401, we throw up a login modal, and once resolved, everything works as expected.

The 401s are retried as are all the queues requests.

We've had good success with this module.

Thanks for working on this Lynn!

Sent from my iPhone

On Jul 22, 2014, at 3:29 PM, Lynn Dylan Hurley [email protected] wrote:

is the request directed to our api? A 401 from another endpoint could trigger a false flag.

shouldn't #3 fix just that? ;-)

Yes! I think so.

the http request itself is a promise - just don't pass it along and retry when it makes sense (after auth?)

I mean that it may complicate things in the user space. Consider the following sequence of events:

the user tries to access a restricted page. access to the page is contingent on the resolution of a restricted api request
the request returns a 401 response
the request is queued
the user is redirected to login page
the user, without logging in, tries to access a different restricted page. this page initiates two restricted api calls (like a batch request)
the requests are queued (now 3 requests in the queue)
the user is redirected to the login page
the user logs in
At this point, which request(s) should resolve?

not all of them, because it's no longer clear which page the user wants to visit.
not just the last item in the queue, because that would only be 1/2 of the batch request
We will need to:

allow for queue invalidation
determine if it's possible to manage the queue automatically. I think that it is possible, but it will require some thought.
I'm working this out now, I hope to have a solution within the next few days.

—
Reply to this email directly or view it on GitHub.

[stryju]

@dehru that's my only issue with the module you mentioned - it will fire 401 and then (an ONLY THEN) add the request to the queue, while IMO it should stop ALL future requests until the "auth" resolution

@lynndylanhurley given your scenario - it should resolve all of them - if the resolution is not handled afterwards, no harm done (testing would be in place, tho)
i really like the idea of queue invalidation - tho it needs some good thought put into it:

• invalidate all?
• invalidate only specific one? if so - reject a promise?

to sum it up - we're here to help - if we can do so in any way - shoot :-)

[lynndylanhurley]

I cannot find a generalized solution for the following scenario:

1. a user tries to access a restricted API route.
2. the request returns 401 status
3. the request is queued, user is redirected to the login page
4. without logging in, the user tries to access a public API route
5. this request will be incorrectly held until the user authenticates with the API.

The client doesn't know which API routes are restricted. It will incorrectly hold all subsequent requests, even unrestricted ones.

The only solution I can think of is to use some kind of opinionated routing convention (where all restricted routes live under a certain namespace), and that falls outside the scope of this project.

Please re-open if I'm mistaken.

[AlejandroSilva]

in my app I use the following workflow:

1. the user access a restricted resource
2. the Apir responds with a 401 error
3. An interceptor get the error respond
4. show a login modal
   At this point several things can happen:

5.a.1 if the user close/cancel the modal
5.a.2 the request of the step 1 fails (finally), and a message is show
5.a.3 the usen can make another action, go to other page, etc.

5.b.1 if the use enter his credentials and authenticate correctly
5.b.2 the interceptor RESEND the request of the step 1, now with the new headers/credentials
5.b.3 the request now have to be successfull

The good of this aproach: don't need a queue for the request, the user can't go to another pages unless it close the modal or authenticate himself