I'm currently creating an EmberJS application,
So obviously my front end is done in EmberJS, and I've decided to go with Go (Golang) as my API service.
I've gotten the back end authentication working using Steams OpenID service
The problem I'm currently facing is, my API runs on localhost:3000 and my front end runs on localhost:4200.
So how can I make a request to my API service which will require human intervention part way through (to be able to type in the username / password on steams website before redirecting back) from my client side.
Right now
localhost:3000/auth/login is to initiate the OpenID request which redirects to steams website
and then
localhost:3000/auth/return is the callback on returning from steams website
I need to be able to some how use this authentication from the client side via some how to be able to authenticate users, e.g.:
$.get("localhost:3000/auth/login").then(() => {
// How the hell am I supposed to login on steams website from here
});
any information would be great as this is really stumping me. If you'd like to see any code feel free to ask, I'm not sure what to provide as everything is working as intended, but I just can't figure out how to connect the API to the client and make OpenID work the way I need to. Thanks!
Side Note: I know some websites will have a popup which the authentication in there (like a twitter or facebook popup) and then refresh the main site after the authentication has been processed I don't know how I might achieve something like that.
Related
I am wondering what is the safe way to login using OpenID in my AngularJS app, with a Node.js backend and socket.io for the real-time.
The thing is that OpenID forces me to use a new window for the redirection dance, so my setup is:
Angularjs renders a view with a button. (this remains open)
The button opens a new window and loads my backend, /auth/openid/
where I set the afterlogin url and redirect to openid site
The openid site redirects to my afterlogin backend
/auth/afteropenid/ where I handle the user data and create a
JsonWebToken.
My problem is that I dont really know what is the best way to continue.
I have to send somehow the JWT to the AngularJS.
One of the ways I see is passing in the query to AngularJS, here I could do everything in the same window, angular > openidsite > angular(with token in querystring). I would configure AngularJS to handle a route and work with the token. I dont know how safe if this, putting the JWT in the querystring seems like a bad idea.
The other way I see is using socket.io, my app already uses this, I am not including it just for the openID login.
When I open the new window, I put the ID of the open socket,
/auth/openid?socketID=XXXXXX
Then, after the openID site redirects back to the backend,
/auth/afteropenid?socketID=XXXXXX , I create the JWT and I send it
using the socket.io to the AngularJS open socket.
In similar questions I see that there is way of doing this by setting a cookie with the token and then making a redirect to the angularJS.
I think my approach would work and has less redirects but I am new to this and maybe I am not thinking in everything, I dont know how could this be exploited since the server only pass user info using the socket. The caveat is that the original angularJS window should remain open but that is acceptable in my situation.
Goal: A single page application that uses Facebook authentication to login, but does nothing with Facebook after that.
Tech: Facebook Javascript SDK, AngularJS, angular-ui, .Net Web Api
I'm creating a Single Page Application (SPA) in Javascript using AngularJS. I'm using the Facebook SDK which is working to authenticate the user; it returns me a facebook user id, an access token, token expiry time, a signed request, and some other stuff, all on the client side. I then pass this information to my service, mostly because I feel I should. After this I don't really care about Facebook. But I want to make calls to the server to load the user's data.
I could just make all requests using the facebook user id, but there would be no security because any client could just call that endpoint and pass any user id until they found a valid one.
I could use the access token on each request as well, but I still think this is a security failure; when the user first logs in and I pass it to the server, well that endpoint could also be called by any client... "LoginServer('myfakeaccesstoken', $knownUserId)
I get the feeling that I should validate the token on the server side back with facebook, and then I can safely rely on teh token on future API calls, but I'm wondering if there are any other approaches?
The Facebook documentation seems to focus too much on me wanting to make follow up calls to their graph API when I really don't care after my user is authenticated.
I have a server running node.js and my client-side is in ember.js.
I'm trying to implement a login system but there is not much on the interner about these two tools working together. I've got a simple authentication system
But what I need to do is the $_SESSION part like in php.
I can login and get my information right away but I don't know how to remain logged in to forbid/allow to go trough certain pages. I need some cookies or something but not quite seeing how I'm going to do this with these two tools.
Thanks in advance
Here are two examples of handling sessions/authentication and login in ember
https://github.com/embercasts/authentication-part-1
https://github.com/embercasts/authentication-part-2
here is a ember-addon
https://github.com/Vestorly/torii
you can store the session token in a cookie, so that when the page is closed the application can retrieve it.
you can send the session token to your nodejs api to authorize the user to whatever resources you are using
I'm developing a new web site that will be a single paged app with some dialog/modal windows. I want to use backbone for frontend. This will call backend using ajax/websockets
and render the resulting json using templates.
As a backend I'll use nodejs express app, that will return the json needed for client, it'll be some kind of api. This will not use server side views.
Client will use facebook, twitter, etc. for authentication and maybe custom registration form.
Client static resources, such as css, js, and html files will be handled by nginx (CDN later).
Questions that I have now:
How can I determine that a given user has the right to do some action in api(i.e. delete a building, create new building)? This is authorization question, I thought of giving user a role when they login and based on it determine their rights. Will this work?
Similar to the above question, will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
Is this architecture acceptable or I'm over engineering and complicating it?
Passport is an option for the authentication piece of the puzzle. I'm the developer, so feel free to ask me any questions if you use it.
I thought of giving user a role when they login and based on it determine their rights. Will this work?
Yes this will work. You can check for a certain role on the user after it's been fetched from the server. You can then display different UI elements depending on this role.
Will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
It wont be enough. Anyone could hop into the console and set something like user.admin = true. In your API you'll need to validate a user token from the request, making sure that the related user has the appropriate permissions.
Is this architecture acceptable or I'm over engineering and complicating it?
At the least you should have an API validation layer. That would make a decent enough start, and wouldn't be over-engineering.
For the authentication part of your question i would use everyauth which is an authentication middleware for connect/express. It supports almost every oauth-social-network-thingie.
For role management you could give node-roles a try. I didn't use it myself but it should help you out, because it checks the role on the server side. Of course that is only useful if your API is implemented in node.js. If that's not the case, you have to "proxy" the API calls over your node.js app.
I hope I could help you! :)
In my work with a Javascript single page application, i have recently run into a problem.
The whole idea behind this project, is to avoid page reload. When the user comes to my application they won't need to make any reloads. This is done with jQuery and Backbone.js and PHP as service.
I have this static index.html file, where i hide my login container and application container. Then i show the login container, if the user is not recognize by my application, and if they have auth i show the application.
if auth:
application.show()
elif not auth:
login.show() // like Gmail or Facebook etc.: Information + login-form
I wan't to show users who aren't authenticated, both login-form and general info. Very important is also that the site can be found by robots as Google etc.
Can this only be done with 2 different files, giving me reload? A site.com and login.site.com. That solution irritates me, because my login, as it is by now, is quite instant.
Not sure I get the question completely but if you want to check if a user in authenticated, try to do an ajax call. If it fails with "401 unauthorized" the user needs to login...
You can achieve what you want by using ajax calls to authenticate (Although this is not a recommended approach, and people usually prefer the two page solution you have outlined).
What you can do, is have very skinny controllers that just exist to provide data to rich client UI.
Your gateway controller(A separate controller, with no model that acts as an entry point in the application) will just render the basic application structure to the client (without any user specific data, you dont know if the user is logged in, you dont need to know at this point). Then the client will query the UserController for identity of currently logged in user, if user is logged in server returns a json response containing information related to user and if not, server returns a response saying that user is not logged in. Then you can fetch a partial for the login form and then submit it again through ajax. As you see, creating the UI once and communicating with the server with lightweight ajax calls can solve your issue easily.