-
Notifications
You must be signed in to change notification settings - Fork 2
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
Automatically handle Simtropolis authentication #9
Comments
Probably not a good idea though to just rawdog the cookie into the url, doesn't feel really secure. A full OAuth flow would be ideal, where the localhost/callback route has to exchange a code for the cookie, but that requires a lot more programming on the ST side. Doesn't look like this os really viable on the short term then... |
Yes, following a standard OAuth flow would be ideal because that's standard. I haven't really looked much into this yet, as the current cookie method works ok-ish. I'm not sure how much work this would be on the ST end or whether we could supply much of the implementation, so getting in touch with ST staff would be good if it's clear what needs to be done. Also, localhost is not |
It looks like the ST forums software, Invision Community, does have support for OAuth at least, but I'm not sure if it's included in their plan.
|
Coming back to this one, I think I might have a solution for the Simtropolis authentication, though I'm not sure if it's ideal. It should be possible to ask users to login to simtropolis.com from within an Electron app and then parse the cookie from the headers sent by intercepting the request - which I know can be done in Electron. Once the headers are intercepted, they can be sent to the sc4pac server. The downside I see to this, is that an Electron app is always massive (~300 MB if I'm not mistaken), so it might be a little overkill just for this, but we could offer it as a separate option for non-tech savvy users I guess. Another possibility I see is developing a Chrome extension, which should be able to do pretty much the same. Downside here is that it might not be approved by Google as it looks an awful lot like stealing user credentials, plus not everyone is using Chrome obviously. |
Ahh, that's not a solution really. I think it would be more reasonable for ST to upgrade their board software by at least one version, which would come with OAuth2 functionality. Upgrading the software is inevitable anyway for future-proofing, IMHO. |
Yes, upgrading the board software is the ideal solution, but I don't know if that's feasible on short term. Anyway, I've created a very simple proof of concept that it's possible to read in the Simtropolis cookies automatically here: https://github.com/sebamarynissen/sc4pac-auth/releases/tag/v.0.0.1-alpha.0 If you're not logged in yet, then you get the possibility to sign in. Once signed it, it will store the cookies, so next time you run the application it already knows the required cookies are present. |
I'm sorry, but I don't think this is the way to go. Signing in in an external application for it to intercept your credential information, that should set off all warning bells against security malpractices. Users will do basically anything if instructed to, but it's not something I'd want to teach to anyone. |
Yeah, I understand. |
I'm not sure whether you tackled this problem already during the development of the gui, but I've wanted to share an idea that I had for handling the Simtropolis authentication in a smoother way.
My idea is to add an
sc4pac login simtropolis
command, which would start a server on localhost:51515 and then open a link of the type https://community.simtropolis.com/auth?return_to=http://localhost:51515/callback in the browser. This page on Simtropolis can then simply redirect to http://localhost:51515/callback?provider=simtropolis&data=<cookie_data> where you can read in the cookie data in the route handler for /callback and then store it somewhere - preferrably set it as an environment variable for the test of the session. If other providers ever require authentication as well, it should be easy too add them to if they implement a similar redirection mechanism.While this approach does require a little bit of programming on the ST side, it isn't much more than performing a simple http redirection if the user is logged in, which can even be achieved with
<meta>
tags if need be. If you're interested, I could reach out to the staff to see if we can get something like this to work.The text was updated successfully, but these errors were encountered: