I have been doing some research on this topic but can never find anything super relevant. I am looking to create a single page application using Polymer. I am building this around a REST API that requires authentication to view is resources.
I have all the details with API worked out but I can't seem to figure out how to handle a login page. Basically what is the best way to keep a user from seeing content without being logged into the application?
Obviously the REST API won't allow data to return to the client but how do I go about preventing a user from going into DevTools and changing some boolean values and being able to navigate through all of the pages, and receiving the 401 errors from all of the Ajax requests trying to fire?
I appreciate any help that I can get! Thanks!
You can't prevent users from changing stuff in DevTools. Just ensure on the server that the user doesn't get data or isn't able to pass data without being authenticated.
Issue a token when the user passes username and password and on the server allow only what the user assigned to this token is allowed to do.
See for example https://stormpath.com/blog/build-secure-user-interfaces-using-jwts/
Related
Since posting on the Disqus disqus forum seems to be a waste of time, maybe someone here can help.
I'm trying to use the OAuth2 flow to connect a Disqus user to my app's account system so I can monitor their activity (posts/comments/etc). I'm using Meteor for my app. I'm calling the OAuth2 authorize endpoint from my server code and passing the resulting HTML back to the client for rendering. This all works fine. But I'm seeing 2 problems on the client side. First, the HTML code returned from Disqus seems to be designed in a full page and the username/password fields extend across the entire window. I was expecting a dialog/modal popup like the one that Disqus provides when logging into a forum. I tried wrapping the HTML inside of a Boostrap3 modal window which mostly works except the username and password fields extend off the right side of the dialog box.
Ignoring the ugly UI the second problem is that when the user clicks on the submit link Disqus puts up and error page titled 'CSRF verification failed (403) - DISQUS'. I'm guessing this may be because the OAuth2 call was made from the server and the submit is coming from the client. If I copy the OAUTH2 url directly into the browser everything works fine. But I don't want to expose my API key and resulting code on the client side since that seems like a security risk.
All I really want to do is verify that the user is trying to connect their own account to my app (and not some other user). I'm not posting with their account so I don't need an access token (I'm calling user/details which just takes the API-key). So I've thought about creating a forum for my app and using the login endpoint to verify the username/password combo. But that dialog doesn't explain the scopes I'm asking for.
I've also considered building my own dialog box to prompt for the username/password, sending those back to the server and have the server "fake" the submit back to Disqus. But that is not a maintainable solution since Disqus might change the expected fields at any time. And it is ugly as sin.
Anyone have any suggestions? I didn't post any code since I don't believe it is a coding problem (and the code is a bit convoluted). But if anyone thinks it will help you help me, I'll be happy to post it. And, yes, I'm aware that not posting the code violates StackOverflow conventions. But I'm taking a chance that the powers that be will allow this post since Disqus support is non-existant and I don't know where else to reach out.
The basic problem was that I was using 'request' with forwarding enabled so that instead of getting the Disqus URL I was getting the Disqus authentication text. You need to render the authentication URL in a window, not the contents. That fixes the CSRF problem.
The next problem is that the URL returned by getAuthorizationUrl is bad. It is of the form 'nullhttps:...'. No idea where the 'null' is coming from, but stripping it off fixes that problem.
To make things easier for anyone looking to do this, there is a shiny new version of the Disqus NPM that includes OAuth authentication methods at https://www.npmjs.com/package/disqus.
I'm building a website using ruby on rails which is hosted separately which makes requests to another backend api rails app which is again hosted separately. Obviously i've setup the backend api with token based oauth authentication.
Now since im not dealing with sessions, and it being stateless n all, How can I stop users from accessing certain view pages in my front end web app? For example, I have a consumer/booking page. I don't want the user to access this page without being logged in. But anyone can just enter the url and open any page they want right now.
On user login (ajax call from .js.erb files), im getting the token and storing it in localStorage variable for every future request to the api. I know I should use this token somehow to stop users from access restricted pages. But I just dont know how.
Now as you have stored the token in the localStorage, you will need to pass this token with the request to the page where you want to restrict access and check if the user is authorized to access the page or not.
TL;DR: there is no standard method or library for this; you must implement such functionality as you see fit.
I'm assuming you're using some sort of front end framework like react; if so, then any request to change the current view should be terminated if there is no valid token in localStorage. Check out this post regarding conditional rendering in React; if you're using something else, the methodology is still pretty much the same.
Otherwise, I would build a small script to include in the beginning of every page that checks whether or not there is a valid token and if there isn't, calls window.history.back() to return the user to the previous page.
(Another way of doing it is to intercept every call to a static HTML file on the server, check if there's a token, and send the file if there is. Otherwise, you can send a custom error page or whatever).
I'm a bit confused. I am trying to provide a simple Google Authentication sign-on.
I would like to use Google's recommended method using the client-side flow: https://developers.google.com/+/web/signin/add-button
If I use this method, how will I keep a user logged in as they move from page to page. I know I can't create PHP session via Javascript.
How can I use the client-side flow and keep a user signed in. I am using PHP on my server.
After spending a few weeks researching, I now understand that I cannot just set a php session variable and stop using oAuth2. I realize that everything I need to get information from Google, I must prove that I have still authenticated that user.
Also, I have come to understand that unless you force prompt, Google will not resend a refresh-token. To provide the best user experience, you must capture the token at first login and then re-use the token to make calls without having to force prompt. This token must be stored in a secured location such as a database for each user.
I've been fumbling around with different client side technologies, like AngularJS, EmberJS, even trying to use straight JQuery and figure out how to use ReactJS with it. That aside, my goal is to build a single page app using json in between the client and a Java Jersey 2 jax-rs back end api.
I have two stumbling blocks right now. Some info though..I am deploying my app as a WAR file in Jetty. My back end is java based. I am using only jquery in the client side as of now.
My main stumbling block is how to handle login, logout and session management. With an rest API and using ajax, I have login working, including it setting a cookie. My concern however is with a single page app, there is just the one index page, and if the user closes the browser, then reopens it to the index page while the cookie/session is still good, the user should be logged in, not see the outside (not logged in) page. I am unsure how to handle this, whether it be a jsp page, index.html with some templating library, etc. With JSP I can insert some scriplet code (against my better judgment). In the old days I'd include a header that would check for request.getSession().getAttribute("user") and if it was there..the user was logged in and using scriplet if() code I'd display a logged in header, instead of the non-logged in header. But I am in the belief there has got to be a better way to do this with todays client side JS frameworks.
The other stumbling block is the navigation and dynamic aspects. For example, when I was messing around with angular js, it was easy enough to use Welcome {{name}} and within the scope replace name with a json response value for the logged in user. In my current situation, I am not exactly sure how to best go about displaying dynamic bits like this with pure jquery other than using some sort of $("#elem-id").innerHtml="..." code within the response success method of an ajax call. As well, I am not quite sure how to handle navigation to different pages. My logged in site will have some drop down menus or links that will replace the content area with different varying amounts of content.
So first, what are some ways in a SPA to handle user sessions, in the case of a page reload, or close/crash browser restart.. to ensure the user is still logged in and direct them to the right page? Second, what sort of templating and routing/navigation options exist that don't require me to put a huge ton of code in my one index.jsp page?
Thank you.
If you're having a REST API as the back end, then you must have implemented oAuth as an authentication mechanism. That is, when your user logs in, using a username and a password, you exchange that data with an authentication token. This authentication token is sent your server with each and every API call and your backend validates this token before servicing the request. Clear so far?
What you could do is, when you obtain the access token, you can also obtain the access token expiration time from the server and store that data in your client side app. In localStorage maybe? And when your user closes the browser and reopens again, you can first check whether such access token is available (and not expired) before asking the user to log in. This should solve your first problem.
Secondly, if you're looking for a lightweight routing option, I recommend director.
I am building a similar application. OAuth is not mandatory. You can have normal sessions etc by hitting the jersey login endpoint and setting a session and a cookie "keepme" with the session if user wants to be persistently logged in. You can then have a jersey AuthFilter for example check if either there is a cookie with a valid session or an active session and keep the user logged in.
Your frontend application should have no say over this, just communicate with the server and if it doesn't get unauthorized access (from the AuthFilter) then continues otherwise it displays the login page.
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.