Closed efagin closed 9 years ago
Session ID is already available through the cookie — the Requests Session. Would it be more helpful to simply expose this as an instance variable?
What's the right way to access that? I guess this was half "XML parsing seems broken" and half "would be nice if this was easy to get, or if that information was at least documented". But if there's a one-liner you could share I think we can just close this out.
Well "XML parsing seems broken" isn't quite incorrect, but it's mostly "chose not to implement all of the different response formats" more than "broken". In this case:
t1 = terminalone.T1(..., auth_method='cookie')
# Initializing with auth_method automatically authenticates
session_id = t1.session.cookies['adama_session']
If you think that parsing the session endpoint has some other value, we can add it in. What you have above I actually do have in Connection._check_session, which gets used as part of the authentication method (basically catching errors from T1):
def _check_session(self):
self._get(self.api_base + '/session')
Thinking about it more, I can see it being useful to expose those as instance variables. You can indeed re-examine the auth you used to see what username has been given, for instance, but it would be very helpful to expose the user ID. Similarly, I can see it being helpful to have an alias for the session ID. The username (which you can access by t1.username
) should have along with it user ID (maybe t1.user_id
?) and session ID (t1.session_id
?)
Those could be useful, yeah. Anything you can get from a login. But if it's all already available somehow, documentation is sufficient, don't need to build aliases. That said, the cookie value you mention above is sufficient for my needs here, so I'm going to close this specific issue.
True, documentation can be good enough. However, I'd like client code not to rely on the implementation details of a session. While the session object is "public" in the not-prefaced-by-an-underscore way, the fact that it uses a cookie as the session ID indicator is contradictory to future authentication schemes. I'd rather alias it as an instance variable so that if the way a session ID is changed in the future, only the class's code needs to change, not yours.
This has a very low LOE and should be out within the next two releases. If you want to get going with something right away, don't hesitate to use the cookie, as that is not going to be going away any time soon. But know that if it changes down the road from cookies, I'm not going to keep t1.session.cookes['adama_session']
hanging around, so it'll be more kosher to use the instance variables.
Got it. Makes sense with that context. Thanks!
The "session ID" is a fairly common element needed for ad-hoc API queries. The client library encapsulates sessions well, but there's an actual "session" endpoint that would be cool to pull in.
Right now I've hacked this as follows:
This is OK, but would be nice if the XML parser actually understood the unique response of the Session endpoint (special "session" tag that isn't parsed by the CLI today):
Note what happens when I try to use the CLI: