0

If I log in into the data SE, it always forgets my login credentials. I have to log in again and again.

I think, the feature is available in the other SE sites, and maybe it wouldn't be very hard to import it into the data SE code as well.

5

This may happen some day, but not without a tremendous amount of thought and likely time. The problem is that Data Explorer is open source (https://github.com/StackExchange/StackExchange.DataExplorer), which means we can't just plug in our authentication pieces. It's quite complicated, and from the SEDE point of view: a lot of baggage for anyone not us.

Maybe one day. Since we're now using cookies for auth up on the second level domains (to prep for the child meta.* moves long ago), it's at least closer to possible.

  • Thanks. But I can't see any trace that it would have access to the data SE SQL port. Although it could make possible for the community to create pull requests from that. – peterh - Reinstate Monica Mar 16 '17 at 19:16
  • @peterh I honestly don't know what you're talking about, what's "the data SE SQL port"? – Nick Craver Mar 16 '17 at 19:22
  • I tried to explain that it is an SQL data management tool, but downloading & compiling & deploying it doesn't mean also access to the stackexchange databases. To do that, they should be mirrored first. – peterh - Reinstate Monica Mar 16 '17 at 19:31
  • Still not sure I'm following, but under no circumstances would I ever give it access to our databases :) At best, it'd be an API call based on the header cookie defined in config that did a lookup to get the account...but that'd tie heavily to our APIs, so it'd have to be generic and...anyway, yeah - this would require API design on both sides. – Nick Craver Mar 16 '17 at 19:48
  • More likely, we'd give SEDE SAML (or similar) capabilities, and try to do that as transparently as possible for the user, so that it'd be generally usable to anyone in a SSO environment. – Nick Craver Mar 16 '17 at 19:49
  • As far I know, behind the data SE is a read-only mirror of the databases, obviously on security reasons. To this DB, having an open TCP port, wouldn't be a serious security risk (compared to the currently available interface to the data SE). – peterh - Reinstate Monica Mar 16 '17 at 19:52
  • The DB access isn't the issue, it's the login, answering the basic question of "who is this user?" - that's completely different in SEDE, and totally disconnected. We'd have to integrate it with the system that knows which account/user your cookie is. – Nick Craver Mar 16 '17 at 19:56
  • Isn't there still the issue that the session cookie expires way more frequently than intended? I forget what the problem was there – Tim Stone Mar 16 '17 at 21:03

Not the answer you're looking for? Browse other questions tagged .