We have two separate websites which essentially share the same UserAuth data store. We want to provide the user with a link from one to the other without requiring them to login again.
At the moment we currently make a call to the target website's API: /auth/credentials which sets up the session and allows us to then redirect the user, bypassing the need go through the login screen. Great.
As far as I can tell /auth/basic should do exactly the same thing. However, the response from the API call is the same but when redirected the user ends up at the login page.
Have I missed something?
Version: 4.5.8
They are not the same, the BasicAuthProvider enables HTTP’s Basic Access Authentication and is a per Request Auth Provider.
Related
I am designing api for mobile application.
I am not sure should I have one endpoint login which will return tokens & user profile
Or have two endpoints and after login call getProfile endpoint.
I saw that people mostly use second option but I don't see benefit of that approach?
Thinking in terms of the single-responsibility principle (which basically says "API methods should do one thing really well"), I'd suggest separating these into two separate things:
POST /login would set up a session and return the session ID to be used in subsequent requests.
GET /profile would return profile information provided a valid session ID is provided.
There are obvious benefits along the "happy path" for combining these, mainly the fact that after a login operation completes, you automatically provide the user with the data they most obviously would want next (who the user is). Why waste an extra API call to find it out, right?
If that's all your API will ever need to support, then there's no reason to separate these. But there are a couple cases I can think of for why you might want them separate:
What if an existing and already logged-in user wants to fetch the latest profile information? This means you must support GET /profile anyway (or have them POST /login again which is wasteful).
What if profile information is already cached and the POST /login API call is only happening to re-authenticate the user inside the app to complete an action? You'd be wasting bandwidth by sending data that's not needed.
Additionally, testing is usually a bit easier when you have each API method doing the one thing they imply they do (POST /login logs the user in, GET /profile fetches the current logged-in user's profile).
I've spent the better part of the day trying to figure out how OpenID works. My goal is to set up a simple site where, upon clicking a login button, users are taken to a Steam login-page, where they are prompted for username and password. After successfully logging in, the user is redirected to a page on my domain, where I collect the query string parameters. They look like this:
{
"openid.ns": "http://specs.openid.net/auth/2.0",
"openid.mode": "id_res",
"openid.op_endpoint": "https://steamcommunity.com/openid/login",
"openid.claimed_id": "https://steamcommunity.com/openid/id/7656119[0000000000]",
"openid.identity": "https://steamcommunity.com/openid/id/7656119[0000000000]",
"openid.return_to": "http://127.0.0.1:8000/resolve",
"openid.response_nonce": "2018-12-01T14:49:46Z30hhn2/[someTEXTendingIN=]",
"openid.assoc_handle": "1234567890",
"openid.signed": "signed,op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle",
"openid.sig": "[someTEXTandNUMBERSendingIN=]"
}
What I am unable to solve though, is the actual authentication issue. I'm not sure what to do with this data. I want to have my own database where I store more information about the user, such as friends, messages, currency etc. For this, it is very important that I can verify that someone didn't just take this request body, change their ID for another and in that way access their account.
I'm pretty sure these are the relevant pieces of documentation, but it still isn't clear to me. How am I supposed to authenticate the user with this data?
I've omitted some values in this post that I fear could be bad to share. These placeholders have been outlined with brackets []. Also, that assoc_handle is really 1234567890, which kind of puts me off, since according to the OpenID documentation, it is used for determining the signature.
To be clear: this page where credentials are collected is not run by me, but is the official OpenID sign-in page for Steam. Steam is a gaming platform. https://steamcommunity.com/dev/ for reference.
For Steam authentication in nodejs you can use Passport.
Passport is an authentication library that works best with Express-based web application.
There is a steam-strategy that can handle your steam authentication.
Check passport here
And this is the Repository for Steam strategy. There is an example folder that you can see how to setup your Steam authentication.
Im using GWT, GAE to make a web app.
I looked at a bunch of tutorials regarding implementing a login system but most of those tutorials implement it so it's mandatory to login to access the web app. How would I go about making it so that anyone can access the app but if they want to use account specific functionality, they they have the option of signing up for an account.
There are two parts to it.
First, in your client code you check if a user is logged in. If so, you allow access to the "closed" parts of the app. If not, you show a link/button to login and hide tabs/views that are accessible to authorized users.
Second, in your server code you specify which requests do not require authentication and which do require it. This is necessary if a user somehow figures out how to send a request without using your client code.
For example, in my code some requests have checkSession() called at the very beginning. If no authentication object is found for this user in session, this method throws LoginException to the client. If the authentication object is present, the request continues to execute normally and returns requested data to the client.
Further to Andrei's answer, if you want a framework to manage the sessions for you, you can use GWT-Platform, which has an excellent Gatekeeper feature.
I use it for mine and I have a LoggedInGatekeeper class. Simply add #UseGatekeeper(LoggedInGatekeeper.class) to the constructor of each presenter proxy and it checks if the user is logged in. If you want anyone to be able to access that page simply annotate with #NoGatekeeper. Easy!
It takes a bit of setting up but it's a great MVP framework. There are maven archetypes and samples etc.
Hope this helps.
I'm in the process of using the facebook javascript sdk to provide user login functionality for a website.
What I'd like to do is simply take the logged in user's unique facebook id and then put/fetch data to/from a mysql database using the id to determine what data is available to said user.
However I don't really feel like this is very secure. Whilst I'm not storing anything sensitive like credit-card details etc, I'd obviously prefer it to be as secure as practically possible.
My fear is that with javascript being what is it, someone could fake the facebook id and just pull whatever they wanted.
I'm aware that the php sdk would provide a solid solution to this problem, but i like the javascript one mainly because it's easy to use and I have the basis of it set up (I admit it, I'm lazy).
So, my questions are:
Would this set up be as insecure as I feel it might be?
Is there anything I can do to improve the security of such a system, other than switching to the php sdk?
Thanks!
Facebook Ids are pretty hard to make up (at most a user will only know their own). Depending on what you store in the database (which will not be anything that the user cannot get on their own, unless you ask for extended permissions)
If you are worried about a user trying to get information from the database, add an access token or signed request to each row and us that and facebook id to get data. That will greatly increase security.
EDIT
There are few occasions where you get a signed request from a user:
* A signed_request is passed to Apps on Facebook.com when they are loaded into the Facebook environment
* A signed_request is passed to any app that has registered an Deauthorized Callback in the Developer App whenever a given user removes the app using the App Dashboard
* A signed_request is passed to apps that use the Registration Plugin whenever a user successfully registers with their app
Signed requests will contain a user id only if the use has accepted permissions though, and are not passed again if the user enters the application, and accepts permissions (meaning that the signed request would not contain the ID). Because of this saving an access token may be a better idea. Here is more on the signed request
Also the signed request is in the url (param = "signed_request"). I always parse it through c# but I am sure you can at least get one through javascript
It's pretty easy to spoof the origin using curl. I'd imagine Facebook has another mecanism in place to make this possible. If you inspect their code, it appears that they generate an iframe and pass requests through. If I had to guess, they have setup the requests to only be made from the Facebook domain, and ensure that the iframe can only be embedded in a page that has a white listed domain.
I work on a Symfony web application which has a standard login form. To allow users to login more easily we want to give them a link which logs them in directly. I've already build a way to get a token to use, but I have no clue as to how the Symfony login process works, specifically how I can adapt it to take a GET/POST token instead of redirecting to the login page.
Any help appreciated!
Oh and this is Symfony 1.2 BTW (and no, upgrading is not an option right now)
Not sure if there are any differences with regard to this in 1.2 compared to 1.4, but in 1.4 I'd suggest taking a look at the sfGuardPlugin's signin() method (or that of sfDoctrineGuardPlugin) to figure out a suitable solution.
$this->getUser()->signIn(... params ...);
That single call will take care of authentication so I think all you really need to do is to resolve your link-specific stuff beforehand (e.g. validate and fetch sfguarduser username & password from db) and then call that method with the user-specific params. Looking at the method will show you exactly what you're passing into it and how it's being used. It's the same one as is being used in the post action of the login form.
Hope that points you in the right direction.
Thanks Tom, what I ended up doing was building a second login module/action (I already had a executeLogin action which basically sets the $this->getUser() and $this->getUser()->setAuthenticated(true) when the username/password is correct) with a token instead of username/password.
Some things to take into account on security: either clear up your token when used in a successful login attempt or set something of an expiration timestamp when creating the token. This way a bot can't 'guess' a token.