I'm creating a simple React-Redux Blog website. So these days i was searching and searching how to do user authentication, and i couldn't find nothing helpful, there were only auth with JWT token, which for me at this moment is really hard to understand so i came to idea, which i don't know is it good or no, so i want to hear more about it.
WHY am i doing this? Because i already made more than half website, but made mistake at beginning because i did simpliest possible auth with local storage, which is really bad...
So idea is to user register with Firebase with email and password.
Then will be created a user in Mongo with unique email(which i will use as ID), and empty other data like username, about section etc, which are not required and which user enters later. So Firebase is only for user login and sign up...
After login i am checking if user is authorized with checking if email in state provided by redux is empty... If is some value in it then i will allow user to do some stuff around...
So i am wondering how i'm gonna deploy it on web and will it work... Any suggestion?
Related
A bit or problem here, well I figured out how to store users signing up from FB/Twitter using SecureSocial, but how am I to register users using email-registration, Can anyone provide me with a brief explanation of how one does it in SecureSocial. I have googled a lot to find tutorials about how thats done, but with no avail.
Yes, of course I can store the token data easily, but in case of email users how am I to integrate the stored data with the user trying to login through the email-password menu. I am confused with the whole work-flow of registering user-by-email
Since I am new to scala, and even new to SecureSocial, I couldn't get the user-regsitration working properly, and didn't properly understand the guide provided in the SecureSocial site regarding this matter.
It would be helpful, if you could provide me with any pointers, or point me to resources/tutorialscovering the part.
Well, I researched about my own question and gained some ideas about Token,
As the name itself describes, Tokens are like real world tokens/tickets:
Tokens-id in SecureSocial exactly are JAVA UUID generated keys, which are unique and used to describe if a particular SecureSocial request is valid or not.
For example if you have used SecureSocial, you might have come accross links like:
http://someapp.com/signup/xxxx-xxxx-xxxx-xxxx
Most imp part of the Token Object, token-id=> xxxx-xxxx-xxxx-xxxx, its unique and you will find them in every links connected to email registration and its other functionalities, like :
Password Change Links
SignUp Links
I 'll try and posting more elaborate answers, after I learn more about SecureSocial.
I am developing a iOS app, that will require the users to log in with third-party SNS account, like facebook, or twitter. However, I want to allocate "native" user id for each users for the benefits of future use.
For example, since each FB user is assigned an unique ID, say, 12345678, when this user log in with his/her FB account, I can get this FB id via FB's iOS api, then I can simply add a prefix "FB" to this id, stored a local text file with "FB12345678" as content in the i-device.
Then next time the app launches, it simply check the existence of this text file, and if not, pop out a view to require users to login, otherwise just use the content, like "FB12345678" as keyword to fetch data from my server.
Above is my own thinking. But I think there are some severe problems:
first, is it safe to store a string locally without encryption?
Second, if I use, say in the example, "FB12345678" to fetch data, is it safe to transmit via the Internet?
Chances are this " FB12345678" can be easily intercepted, and used to forge the identity of a user.
Lastly, if the user changes his/her FB password, I think my app should require the user to re-authenticate, but from the above strategy, obviously it does not work out.
So could anyone elaborate what is the most commonly used strategy, or algorithm, to enable thirdparty SNS account login? (like Instagram, Parse, etc.)
you can use the SDKs Provided by different Social Medias. It will maintain the session at your side. It is not proper to save userid on application side and other thing is that in almost all the medias you will require to send the access token and secret to request a data. and the Token Changes so its not good to save it. You can send it with your request and if it will be expired it will automatically ask you for the second time login.
please visit:
www.developers.facebook.com //for facebook
www.dev.twitter.com // for twitter
Try following links:
https://github.com/fhsjaagshs/FHSTwitterEngine
https://github.com/nov/fb_graph
hope this will help you.
It seems that basic functionality such as user login, can not be done in simple manner: to have username and password field in form on client and based on that to create store.readPathAccess model access rights. Also, how to check if user is logged in to implement access rights on routes?
Based on examples and (poor) DerbyJS documentation, if I understood it correctly, you have to implement login in server module (lib/server/*) because:
store.readPathAccess must be used in server side
you want to store data in model session (which can be read only on server side)
But many questions arise:
if it has to be done on server side, how to get and store client form data on server side without having problem with second item below on the list (I have done it with manually submitting data to server-only route, but can not then save it in model with local key because I have to redirect to client route after that and local model data is lost)
how to read later that data if it must be stored in session?
even if the store access rights for model is managed, how to check if this specific user is logged in when in client routes?
I'm quite confused at the moment... liked Derby principles, but this authentication problems are playing with my nerves seriously.
I know I may not be quite clear, but there are many points to go in details and if anyone can help I'll gladly give more required info.
Thank you,
Eddie
I found this library today called derby-auth.
It uses passport for signing in and has a good example using a simple register and login form.
What it does is to set some routes on the server for logging the user, and a middleware to tell the client if it's logged or not.
It does have some bugs (a few callback calls missing that break some things), so i wrote my own based on that, but must clean a lot of things before uploading anywhere.
i'd be glad to send it to you if you want to, though.
The most current library is https://github.com/derbyparty/derby-login
It has been updated pretty regularly and works with derbyjs 0.6
I'm slowly beginning to unerstand REST and theres one thing thats confusing me .
I understand that most of the things in REST is a "resource" . So i was wondering what kind of a resource would we be referring to in the case of a user signup / login ?
Is it users ? Then does it mean that a POST on users would signup for a new user . If that is the case , then how do i authenticate a user ? a GET on users with an encoded password / username pair?
I'm really confused with this.
I may be COMPLETELY wrong in my understanding given that i'm just starting to understand REST.
Any help is appreciated !
Thanks!
It's a bit of an unusual but common problem for REST. Keep thinking about resources.
When you login you're asking the server to create a session for you to access certain resources. So in this case the resource to create would be a session. So perhaps the url would be /api/sessions and a POST to that url with a session object (which could just be an object consisting of a username or password and perhaps the UUID) would create a session. In true REST you'd probably point to a new session at /api/sessions/{UUID} but in reality (and for security purposes) you'd probably just register a session cookie.
That's my own personal approach to login forms if I were to implement them myself but I always tend to use Spring security for that job so this requirement never really takes much consideration.
I am working on something similar and this is the solution I have taken so far. Any suggestions welcome :)
I have users exclusively for singup and account modifications.
GET /users/{id} gets a user for the profile page for instance
PUT /users creates a new user with username and password. In reality this should send an email with a link to somewhere that confirms the signup with a GET method.
POST /users/{id} modifies the user (for example change password)
DELETE /users/{id}
For authentication I tend to think that the resource I request is the token or the authentication. I have tried to avoid the word "session" because it is supposed to be anti-RESTful, but if you are just creating the illusion of an actual server-side session for your clients, I guess it is fine.
PUT /authentication/ with usename/password returns Set-Cookie with the pair user_id / hashed value. Maybe it should be POST. Not sure
DELETE /authentication/{user_id} just deletes the cookie and the user is signed out. Maybe instead of user_id it should be a unique token_id.
Resources can be created, read, update and deleted using a restful approach, see e.g.:
https://cwiki.apache.org/S2PLUGINS/restful-crud-for-html-methods.html
So if you'd like to administrate you users this would be the restful approach to do so.
If you'd like to authenticate the users which you have in your administration dataset you need
to design or select a restful authentication mechanism see e.g.
http://de.slideshare.net/sullis/oauth-and-rest-web-services
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
For a jumpstart on these issues you might want to check out dropwizard:
http://dropwizard.codahale.com/
A resource may have one URI or many
but One URI will have exactly one Resource
Therefore, When Authenticating a user, you are addressing a user who is already registered
While when registering, you are addressing the user (resource) which is yet to be registered.
All you need is a way to process it to your SERVER.
THIS is an example taken from SUGARCRM REST web services implementation.
REST is like http requests to your SERVER.
For eg, when implementing REST Web Services.
Every REST Request is going to same File say
www.your_domain.com/Rest.php?json={your_json_method:'method',params:'watever'}
Where in Json is the request you are sending as a parameters
Requesting to authenticate a user
{method:'SignUp', username:'abc', pass:'pass', confirm_pass:'pass'}
Requesting to register a user
{method:'Login', username:'abc', pass:'pass'}
by this way you can have as many params as you want
Remember JSON is not necessory to be used. you can use simple get params for your query
On my iPhone Facebook app I think I've only logged into it once.
On my Mint financial app, I've logged in once. whenever I load it back up, I give a four digit PIN number which was setup in the app, and I never have to log in again.
I'm building an application right now where this type of behavior would be highly beneficial.
Do they just set an auth cookie of some sort and just set it to expire way into the future? Or is there another way of handling this?
Thanks!
You can use the iOS KeyChain to securely store credentials as well. This can be simplified by using this code found on github ( https://github.com/ldandersen/scifihifi-iphone/tree/master/security/ ) , with some basic instructions found at http://gorgando.com/blog/tag/sfhfkeychainutils
That depends on the context of your application. If you authenticate against another API, the supplier of the API usually provides you with some sort of authentication key which might expire after a certain time. You would store this key in your application once the user performs the authentication step and reuse it for every request.
Basically, the data you have to store and the time before your user has to re-authenticate (if ever) depends on the supplier of the API you're using.
I can't speak for Facebook or Mint, but the simplest approach is to use a cookie / token and store it in NSUserDefaults.
When the application is launched, see if token is still valid. If not valid, force the user to sign in again.
I am taking a stab in the dark here, but:
I am assuming the login information is encrypted and then stored on the device somewhere. Upon creating a new instance of the app this data is sent to the site for all of the oauth/login/etc stuff. Once this is done the Facebook app stays on until: 1) the device is turned off, or 2) you manually quit the application.
Maybe this will start to help you, but I am sure better answers will come.