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.


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
    Mar 16 '17 at 19:16
  • @peterh I honestly don't know what you're talking about, what's "the data SE SQL port"? 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
    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. 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. 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
    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. 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 .