Comments (8)
Hi Adrian,
Good question :)
If the access token wasn't deleted, and you were using route validation, you would need to explicitly add a validation rule for every route created to allow the access_token to be passed through, which shouldn't be a requirement. It allows for a separation of concerns where this module handles your auth and your routing config and validation is just for that.
Does this pose issues for you?
from hapi-auth-bearer-token.
OK, that makes sense!
We're using HABT on only one route, /login so we haven't bumped into that.
The reason I ask is that I'm now creating a /logout route and I need to implement the same logic you have in lib/index.js that attempts to extract the access token first from the auth header, then the URL.
I was thinking to pull out that logic into extra functions so I could call HABT.getAccessToken().
It doesn't feel 100% right as it's more of a utility function.
Will ponder on it some more...
from hapi-auth-bearer-token.
Is the project you're working on github? I'd be curious to take a look if so.
Am I right in assuming on the logout you're hoping to retrieve the auth token to invalidate it on the logout route or something along those lines?
from hapi-auth-bearer-token.
It's not on GH unfortunately.
Yup, that's what I was looking to do.
Am I missing a trick in getting access to the access token?
from hapi-auth-bearer-token.
Well I'm actually just wondering what you're doing with auth in the mean time, for the /already_logged_in routes.
If you're storing authentication in the cookie from then on, you could also store the auth token. When I have a user authenticated, I store the auth token among the user's credentials by passing it back in the strategy callback:
callback(null, true, { token: token }) // this line in the example on the readme
so it is then accessible from request.auth.credentials.token.
I think I'd need to understand your full use case in order to be able to offer any more advice though.
from hapi-auth-bearer-token.
All routes are using auth barer except for /login with is using auth basic (This is likely to change).
We're leaving it up to the client to choose whether they send the barer token in the URL or as a header.
I'd like the route /logout to not be any different to all the other routes in that I can call /logout?accessToken=123 or /logout (Barer base64 rep. of 123).
So I need to do the same logic as in your plugin, first look in the headers, then the URL.
Does that seem like an OK plan?
from hapi-auth-bearer-token.
Ah I misunderstood, I thought only /login was auth bearer.
That all seems perfectly ok in that case. So my advice:
- Store the auth token in the credentials object from the authentication strategy, so you have access to it throughout the app like in the example above.
- Also use HABT for the /logout route, so when they call /logout?accessToken=123, you can access the token from request.auth.credentials.token for you to mark invalid etc.
Let me know if this poses any problems.
from hapi-auth-bearer-token.
Hi Adrian, going to close this issue, but feel free to comment or follow up if the above approach doesn't work for you.
from hapi-auth-bearer-token.
Related Issues (20)
- Undefined token passed to validate function HOT 3
- Version 6.0.1 typescript not job HOT 3
- Required plugin HOT 4
- add git tags that match published versions HOT 2
- An in-range update of joi is breaking the build 🚨 HOT 3
- if validation fails, please make credentials object to be optional HOT 7
- An in-range update of joi is breaking the build 🚨 HOT 4
- Error 500 on invalid token HOT 22
- Double validation error HOT 1
- An in-range update of code is breaking the build 🚨 HOT 4
- An in-range update of boom is breaking the build 🚨 HOT 2
- An in-range update of hapi is breaking the build 🚨 HOT 5
- Exception when allowChaining is true and the strategies are defined via default auth value HOT 1
- How to customize own error? HOT 8
- Update & bump 🏷 HOT 2
- "Error 500, invalid token, data null" when recalling the previous token in Alamofire HOT 1
- allowMultipleHeaders: true should allow read two headers as array in token HOT 5
- Library does not work with the new independent "joi" library which has now split from @hapi/joi HOT 1
- version 8.0.0 HOT 3
- New feature: multiple auth token names HOT 6
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 hapi-auth-bearer-token.