These are chat archives for cherrypy/cherrypy

21st
Jun 2016
Jellyfrog
@Jellyfrog
Jun 21 2016 14:28
hey guys, We have a salt-api running via cherrypy, Im trying to get it to share sessions via memcached, i simply try to reuse the token I get from /login, but that gives me http 401, any tips?
(i.e. we have multiple instaces of salt-api/cherrypy ) on the first instane i do /login, i get the token back, and then i can use it like normal, its on the second insance it gives me 401
Joseph S. Tate
@josephtate
Jun 21 2016 14:53
@Jellyfrog you may need to modify some code, the sessions may be tied to IP address
I'm just spitballing though
Jellyfrog
@Jellyfrog
Jun 21 2016 14:55
well on my second instance it seems it kinda finds the session, but it still gives me http 401 ..
[21/Jun/2016:16:42:57] TOOLS.SESSIONS ID obtained from request.cookie: '76d033e602c8f800c56ba5caf7365941272b9eea'
[21/Jun/2016:16:42:57] TOOLS.SESSIONS Data loaded for session '76d033e602c8f800c56ba5caf7365941272b9eea'.
Joseph S. Tate
@josephtate
Jun 21 2016 14:56
can you trace where the 401 is being raised? That'll give you a clue as to what condition is failing
Jellyfrog
@Jellyfrog
Jun 21 2016 15:01
might be in salt-api, looking into it
Joseph S. Tate
@josephtate
Jun 21 2016 15:05
you may find cherrypy.request.show_tracebacks = True helpful
Jellyfrog
@Jellyfrog
Jun 21 2016 15:11
ok i guess i found it, salt-api is not working as i thought prolly. I forgot to say we have different salt-masters for each instance, i guess the login does more than just giving me a session,
so i guess i need to do a /login for each instance and keep track of the sessions
Joseph S. Tate
@josephtate
Jun 21 2016 15:14
That doesn't sound right to me
either your second instance isn't really seeing the data in memcached, or your client isn't set up exactly the same when making the second connection
Jellyfrog
@Jellyfrog
Jun 21 2016 15:17
like i said, each instance have its own salt-master, so im guessing the problem is there somewhere
the token might be bound to that specific salt-master or something
and not just the salt-api layer
but im just guessing :)
Seth House
@whiteinge
Jun 21 2016 15:35
@Jellyfrog you're right. Authenticating/authorizing a command happens on the Salt master. salt-api just maintains the mapping of session tokens to Salt tokens.
Jellyfrog
@Jellyfrog
Jun 21 2016 15:36
Thanks for clarifying :) Rebuilding the logic atm
Seth House
@whiteinge
Jun 21 2016 15:38
Salt doesn't currently have a way to share Salt tokens between multiple masters. There's an existing issue to make the minion key storage a pluggable interface, it would be an awesome addition if eauth tokens could also be stored external to the Salt master.
Jellyfrog
@Jellyfrog
Jun 21 2016 15:41
I see. that makes sense. Since we use single sign on I only see the users password once, I guess I have to call each salt-api instance during login to get tokens
whiteinge @whiteinge nods
Jellyfrog
@Jellyfrog
Jun 21 2016 15:52
thanks for the help guys
Seth House
@whiteinge
Jun 21 2016 15:53

@Jellyfrog salt-api session tokens are pretty short-lived, they use the same expiration as Salt eauth tokens plus they're in-memory only. Salt eauth tokens can have arbitrary expirations and can be copied between multiple masters. But that functionality is not exposed to users.

This may be relevant to your effort. It'll be in the next major release (Carbon).

saltstack/salt#33296