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.
Related
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.
Help! I have no clue what I am doing here. I am reworking old C# code and I need to use LDAP for integrated authentication on an intranet. The user should be completely unaware of this process but what I need is to have the React page contact the express server passing in the users domain id. From there I need to perform basic authentication then return all the groups that this user is a member of for validation.
I have read numerous tutorials on passport-activediretory and passport-ldap and so on but I am still confused.
What I am looking for is a single function that will run on every call to the API and will return either validation or, if requested, validation and group names the user belongs to.
What is available to make this process very simple. I looked at passport but to be honest authentication is not my milieu so I am at best uncertain as to how any of it works.
I am hoping that it will be as simple as app.all("*", functionHere());
Being very new to node (first project) I really need extensive help, hopefully in small words.
Thanks
For now I have switched to a .Net back end which support for LDAP integration without the need to a lot of excess code.
Will move back to Node once the application is finished then port it over.
I'm currently searching the best way for developing my next webapplication. I'm thinking about using Backbone.js and build a single page application. But I really can't imagine how to secure my app since nearly everything is done on client side. Of course I just could prevent the users from accessing my RESTful Api so they would not have access to my data. But all the view/model/collection/template js files are still accessible.
Or is there a known way to serve the js files with php (laravel), which would allow me to only serve the files I need for the respective user.
I just couldn't find a solution by searching the Web. But I just don't think that I am the lonely person who needs a clean and secure authentication method including different user rights.
Thank you in advance!
Your backend application will fetch data from a backend (= API), and probably send back some changes.
This code can't have "security holes / leaks" as long as your backend is secured.
If you are afraid of people stealing your code, you can always minify the JS (check grunt.js and almond.js for this)
To secure your backend you can make use of Laravel's auth class, and the auth filter as mentioned before.
Besides normal auth, you could implement roles, that you can assign to specific users, giving them more or less access to certain resources in your backend.
Here's the method I would try :
Separate the application in two parts.
One part - login via regular Laravel Auth on a separate page, and then when the user is logged in serve the single page app in a different view.
Wouldn't this work?
Web Services are no different than any other web application you build. At the end of the day you are exposing functionality to the client (which is also the attacker). It doesn't matter what the client is implemented in, if you expose dangerous functionality you will be hacked.
Have a session state, keep track of the user id and make sure that the user is only accessing resources they have been allowed to access.
I do not think that what JS/template files are exposed really matters. Essentially, you should only be allowing data interaction to authenticated users. Think of this as two separate applications.
The front-end application logs in, and a cookie is stored (or some other persistence is used).
The back-end application then uses the persistent authentication to validate every single user request for data, and every user action.
This way you don't have to worry about the security, the client can only fetch the data that the server allows it to, and, likewise, it can only interact with the data insofar as the server allows it. You shouldn't be relying on the client side for security anyway, even logged in, otherwise some malicious user could, conceivably, save all your frontend code and use it against you without authentication.
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'm sure there must be a simple answer for this but I can't figure it out -
I have a Silverlight 4 OOB application that requires a login screen/security. The View shows a LoginView (Username/pw) which then passes the details to a WCF service and checks it against a database. It will return a result to the client to say if their details were valid or not. This part works fine.
Where I need some guidance is the best way of storing the fact that the user is logged on/authenticated for the current Silverlight session.
It's OOB so we can't use any web cookies/session stuff as far as I know. I assume we have to store some sort of Identity in the thread but I need some pointers please.
The other caveat is that I would like to secure all other pages to check if the user is authenticated and redirect to the login screen if not. I use the Navigation framework so I have a Frame - this may make it easier...
Any tips or pointers appreciated - I just need some ideas to get started please.
Just store the fact that the user is authenticated anywhere you like - I tend to like the Application object since it's an app-wide setting, but you can stick your "IsAuthenticaed" and/or "Roles" properties anywhere, really.
Take a look at WCF RIA Services - even if you don't want to use their solution, you can take a look at the generated authentication code it makes and see a good real-world example of how this can all work.
As for redirecting if the user is not logged in, I suggest using an INavigationContentLoader on your Frame, which can implement this logic in a central location. See these two excellent posts by David Poll on the subject of INavigationContentLoader and authentication/authorization:
http://www.davidpoll.com/2010/01/01/opening-up-silverlight-4-navigation-authenticationauthorization-in-an-inavigationcontentloader/
http://www.davidpoll.com/2010/05/10/common-navigation-ui-and-authorization-driven-sitemaps/