For an assignment I have to make the CMS-system easily accessible trough mobile devices. Ideally we would like to create a way for user authentication with the least amount of input possible.
I have created a system with php/javascript which mimics the android pattern lock, so at this moment a user can login by swiping a pattern. But the problem remains that they still have to manually type a username.
Would it be possible to get some sort of unique ID from a smartphone, so we can store this in the database and link it to an account. So that if a user wants to login in to the CMS, he only has to browse the website, the system will recognize who he is, he swipes his pattern and the user is authenticated!
Unfortunately, it is not possible to get a unique device id from a browser.
However, you can do it like this:
If remember me is checked, you can set a cookie on the client's browser where you store the username. Next time the user opens the page, you check if the cookie is set. If so, you prefill the username.
This way the user would only have to enter the username the first time and it will be prefilled until he deletes the cookies of his browser or the cookie expires.
Related
I try to implement sign up AWS Mobile Hub process in an iOS app. I chose "How are your users going to login?" only email option. But the test app (downloaded from 'Integration Steps' page after User pool creation) have required Username field on a sign-up and log-in screens.
Can I implement this flow with user email and password fields only?
It should be possible, though you might have to autogenerate a fake username on the first sign up. You should make sure email is then passed in as an attribute and is set as an alias for the pool.
One possible sticking point: if email and phone are both given to be confirmed, phone overrides email. In that case, you'd have to ensure manually that emails are confirmed.
I need to log in a user into Dropbox using Core API. Then remember his/her access token and allow logging in with another credentials (looks like a second Dropbox user). But when I make request to https://www.dropbox.com/1/oauth2/authorize it automatically ends up with redirect page with first user's access token giving no chance to enter another credentials. I know I can revoke first access token but then I will not be able to silently come back to first user.
Does anyone know is the possible to implement?
You can set the force_reapprove parameter for the /authorize page to true to prevent the automatic redirect:
https://www.dropbox.com/developers/core/docs#oa2-authorize
Note that the /authorize page is hosted on www.dropbox.com though, so the user will get their www.dropbox.com session, even if force_reapprove=true is set. With that parameter set though, the user has the opportunity to switch accounts, using the dropdown in the upper right of the page, before authorizing the app.
If that's not sufficient for whatever reason, you can try to end the user's www.dropbox.com. The simplest way is to direct them to www.dropbox.com/logout first. Be sure to make it clear to the user what is happening though.
Or, if you control the entire browser, e.g., if it's an embedded web view in your app, you can clear the browser's cookies, which will clear the session, forcing users to log in again.
Using Parse.com, I want my users to login only with their phone number, just like WhatsApp.
Enter your phone number, get a verification code by SMS, enter the code - you are logged in and stay logged-in!
I can see how I can use Twilio to send a verification code.
My problem is how to tie it in with the Parse authentication framework.
When to use signUp vs login?
What is the password?
What to do the second time the app is launched?
What to do when the application is re-installed?
I don't think you should use the predefined Signup and login classes provided by parse as they do not allow you to create a user without a password,
Nor should you use the Anonymous Users as the data will be lost once the user sign out/uninstall.
For Signup, Use another object to store the numbers , Implement a onSave hook in cloud code to ensure that all the username"phone nos" are unique during Signing in.
For each device, perform an OPT(one time password) to the phone of the user by using the installation class's id
Perform a query and load the data connected to the number during Login
To keep the user logged in , use the local data store , pin a Boolean variable that indicates the status of a user, either logged in or out.
In the parse DB , You can use the phone num as the link to the other data of the user.
In this way, no password , only OTP
You will need to store something on the user settings/profile to pin that user, I do not recommend using a boolean but rather something that ties that device with the user so that if someone decides to copy that file and paste it into a rooted phone you will be able to determine if the app install corresponds to that user.
I would recommend using the a unique token to create a password for a user in Parse.com - you can use the token that RingCaptcha generates for this, ensuring it will never collide with other users and that every phone number will only be able to verify one time for each device. RC is a new service that helps you onboard verified users into your apps in seconds via SMS. Integration is a breeze with all the available plugins for web, APIs, and SDKs of all flavours.
[Disclaimer: I'm part of the team behind RingCaptcha]
I have a website that uses OpenID to sign in users. The library I'm using, returnes a user profile when the user logges in. This profile contains user's email, name, a link to the avatar and an ID which the OpenID provider has returned.
My strategy for keeping the user logged in is this:
When the user logges in for the first time, I create a hash code based on the OpenID's returned ID
I store this hash code alongside the user's ID in 2 cookies.
When the user comes to my website, I check for these cookies, and if they're available, try to match the ID and the hash code, if it's correct, I log the user in.
Now the problem is this: if somehow this cookie information gets stolen from the user, the hacker can easily log in instead of the user himself. I could create a new hash code for each time the user logges in and update the user's cookeis but it'll make the information of other browsers/computers cookies invalid.
Since the StackOverflow website does not suffer from such problem, I would like to know what should I do to both secure my login strategy and add the functionality to stay signed in for the users.
The standard way to do this is to assign a meaningless session ID and send that as a cookie; in your database, you can store the user's credential information alongside that session ID. When a user logs out, you can invalidate that session ID.
Isn't this a problem with ALL mechanisms for letting the client stay logged in? If you log into your, say, gmail, and I steal your cookies, and put them in my own browser, there is no way to distinguish my browser from your browser and I get access to your gmail. There's no way to stop the kind of attack you're suggesting, I believe (other than the user keeping their computer free of viruses etc. that could steal the cookie)
Well, you type username and password in form, hit "OK" button. Then data going to server side and check users database if that user is existed. Then it return user id. And what next?
That data is saved in cookies?
Does it mean, that with every clicked link, site login you to website again?
I mean,
you click some link on site
browser redirect you to that page
site checks your cookies
site grab username and password from cookies
site checks is that data is valid (via connecting to database)
show page to you
Is that correct?
User enters credential.
System validates credential.
Upon successful authentication, server saves user object into session.
System grabs user info from session.
System displays webpage.
Tadaa!! :)
UPDATE
To add a little more...
User visits the secured webpage.
System checks if session contains a user object.
If user object exists in session, allow user through to visit the page.
If user object doesn't exists, redirect user to login page.
You don't need to store user password in the session. In fact, it is highly discouraged. Checking to make sure the user object exists in the session is sufficient.
When the user clicks the logout page, then proceed to invalidate the session... that's it. :)
Almost correct. You rarely go to the database with every request. You usually set a cookie with a expiry date and save the user session and info in memory. So every time a request is made, if the user is not authenticated, you authenticate him, generate and send him a cookie with, say, 5h expiry. So, in the next 5 hours, whenever a request comes in with that cookie, you trust that the user is an authenticated, valid user and you don't have to check the database.
It's not how every site does it nor it is the only way to manage session and cookies but I think it is the most widely used.
You should probably use sessions, but that's pretty much the gist of it. That way the data doesn't accidentally persist.
I mean, for my simple site at home, that's how I do it. But it's still locally hosted, so the security is guaranteed to be crap.
Oh, and no need to check with the database whenever you click on another link -- too much time wasted.
Typically, an application takes advantage of the session that is established between the browser and the web server, and makes a note that that session is "authenticated". "session" is a built in feature of HTTP. If the browser is closed, or after a certain period of time passes, the session is automatically closed. If the user does an explicit logout, the application marks the session as not-authenticated.