Comments (12)
This is a nice package that I have used on 2 products that solves this for you.
https://github.com/witoldsz/angular-http-auth
from ng-token-auth.
Thanks @dehru! I'll look into this asap.
from ng-token-auth.
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
from ng-token-auth.
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)
.
from ng-token-auth.
@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 :-)
from ng-token-auth.
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 responsesother than this - it works great :-)
—
Reply to this email directly or view it on GitHub
#2 (comment)
.
from ng-token-auth.
- 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? ;-)
from ng-token-auth.
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.
from ng-token-auth.
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.
from ng-token-auth.
@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 :-)
from ng-token-auth.
I cannot find a generalized solution for the following scenario:
- a user tries to access a restricted API route.
- the request returns 401 status
- the request is queued, user is redirected to the login page
- without logging in, the user tries to access a public API route
- 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.
from ng-token-auth.
in my app I use the following workflow:
- the user access a restricted resource
- the Apir responds with a 401 error
- An interceptor get the error respond
- 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
from ng-token-auth.
Related Issues (20)
- auth:password-reset-confirm-success never seems to be broadcast HOT 1
- Refreshing multiple times causes token failure/loss HOT 2
- Make a new release HOT 7
- Info on Support of this token for Angualr js 1.x HOT 2
- submitLogin unauthorize user
- how to broadcast 'auth:logout-success' if i logout using my own method HOT 1
- config is undefined HOT 1
- Quota Exceeded errors from setItem() when running on Heroku HOT 1
- submitRegistration without Confirmable?
- Unable to persist session after refresh HOT 6
- Live demo doesn't send registration emails HOT 1
- $auth.validateUser undefined in safari. HOT 1
- ng-token-auth depends on Express 3.x
- Project status HOT 1
- Unhandled rejection on failed login, even with catch()
- token headers not being stored
- package supports angular 6? HOT 2
- postMessage handler doesn't verify origin
- Create new release for package.json fix
- C
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ng-token-auth.