-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding secondary session sharing #11
Adding secondary session sharing #11
Conversation
console.log("EREZ handleSSOLogin: req.query = ", req.query); | ||
if (req.query.user_token) { | ||
console.log("EREZ handleSSOLogin: req has user token!!"); | ||
req.query.access_token = secondarySessionTokens[req.query.user_token]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the implications of not having a session token in the cache?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can simply remove the token from the cache once the new session takes it and insert it into it's session.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the implications of not having a session token in the cache?
if ManageIQ did not insert a new session token to the cache ~immediately before the user starts a new session, it means the user is not authorized. This is why it is safe to remove the token from the cache once it's consumed by the user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the implications of not having a session token in the cache?
Do you mean what happens ifreq.query.user_token
is not insecondarySessionTokens
?
Thenreq.query.access_token
will be set aundefined
and the authentication using it will fail and the user will be redirected to authenticate with Openshift.
@@ -8,6 +8,8 @@ var sessions = require('client-sessions'), | |||
config = require('./config'), | |||
parseDuration = require('parse-duration'); | |||
|
|||
var secondarySessionTokens = {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we be concerned with the cache growing without bounds? Do we need to purge periodically?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can also keep just one (Two, Three, N ?) and pop it once it is used. How does that sound?
@jcantrill I have changed to use an LRU cache to store the user token. I added a dependency for "lru_map" for that. Please tell me if this is acceptable. |
0b22254
to
b45f901
Compare
@@ -7,6 +7,10 @@ var sessions = require('client-sessions'), | |||
bodyParser = require('body-parser'), | |||
config = require('./config'), | |||
parseDuration = require('parse-duration'); | |||
LRUMap = require('lru_map'); | |||
|
|||
var secondarySessionTokens = new LRUMap.LRUMap(10); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would allow this to be initialized via an env var that defaults to 10. Concerns here of what this would mean when used at scale.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 will do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
@@ -26,6 +26,7 @@ | |||
"passport-oauth2": "^1.1.2", | |||
"request": "^2.60.0", | |||
"url-join": "0.0.1", | |||
"yargs": "^3.18.0" | |||
"yargs": "^3.18.0", | |||
"lru_map": "^0.3.2" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@richm This will have impact on packaging the auth proxy for openshift.
b45f901
to
5219d60
Compare
5219d60
to
26fe567
Compare
I joined all the commits here and updated |
@@ -1,4 +1,4 @@ | |||
FROM node:0.10.36 | |||
FROM node:7.3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you use node:4.7
? This will make downstream integration much easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No.. It throws this error:
/usr/local/lib/node_modules/openshift-auth-proxy/node_modules/lru_map/lru.js:78
let entry, limit = this.limit || Number.MAX_VALUE;
^^^
SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at Object.<anonymous> (/usr/local/lib/node_modules/openshift-auth-proxy/lib/authHandlers.js:10:22)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
I will see how to change this module if it is not possible to accommodate this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I changed lru_map
to lru-cache
and all seem to work now without touching the base node image. I guess this is the best solution.
LGTM. I defer to @richm and any objections he may have. I'm mostly concerned, if anything, with the production implications of the node change and the added libraries. |
Allowing clients to stash the authentication token in the proxy and transfer the session to another user/client with a different token. Users tokens are saved in an LRU cache whose size is configurable.
26fe567
to
e8d20cf
Compare
ping @jcantrill @richm I changed to use a different LRU that doesn't require any image changes. PTAL |
LGTM |
Adding two endpoints "/auth/sso-setup" and "/auth/sso-login" to allow giving a 3rd the ability to authenticate without actually sharing the token with it.
@jimmidyson @sosiouxme @simon3z