I want to implement logging in for users, and regard them as "logged in" during their surfing (using sessions). I do it on Google App Engine with webapp2 framework. But the platform is not important, I'm sure you will point out the general rules to do it.
I have written the class Authorization with authorize method, and every handler inherits from this class. When some handler is triggered I first run self.authorize() and it checks whether the user has the session variable holding his login. Then I check the internal datastore to find out whether the user's session is expired (so I don't depend only on the info from the client's side).
How can I improve or simplify this approach? Do I have to do the authorization routine from every handler or I can keep it in one place?
Also the way webapp2 implements sessions look strange to me. I have to make a class with dispatch and session methods that do some magic. And if a handler inherits from this class I can use sessions inside it:self.sessions['login'] = 'Joe'; self.sessions.get('login').
Related
I have a django project where I need to know how much time each user spends on the site.
The first thing that came to my mind was that since I have a CustomUser I can create my own login/logout view and populate a table with login and logout and the user's identifier. However, I wanted to know if there is a callback function for django.contrib.auth.urls. So I can use the default login form?
You can use Django Signals. Django has several built-in Signals that trigger when various events occur. For example, post_save and post_delete. You can write handlers that listen for these signals to trigger whenever the session (or token, JWT, so on, depending on your authentication backend) is created or destroyed. You can then perform actions (like updating a database table) whenever these events occur.
I had a question regarding best practice when it comes to building a global utility class in EmberJS when the class will exhibit user-specific behavior.
The following conditions are all true:
The class's methods could be accessed from anywhere in the entire application.
The application performs JSON based authentication using Ember-Simple-Auth.
The authentication confirmation payload comes with some information about the user.
The information received in the token payload will determine the behavior of the utility class's function.
My Questions
Is a Util the best option?
Should I be using services and somehow "initialize" this service on a confirmed authentication? My end goal is to use this class from almost every route/template/component in my application.
How chill are authentication payloads? Is it OK to send crumbs of user specific information information in the authentication payload in addition to any tokens?
The best choice is using services.
They are :
singleton
could be injected to any object extended from Ember.Object
Is a Util the best option?
No. Services is best option. You can initialize it after successful authentication hook of ESA. And it could be injected everywhere
How chill are authentication payloads?
You can send anything. Your authenticator is responsible to process it. The payload is saved in data.authenticated object in ESA session service
I am trying to implement security for my project that prevents session fixation.
As i have no access to the component (a filter from a certain library, lets call it MagicFilter) that handles the whole session-creation and validation, i was trying to find out another way of possibly doing it.
Now, consider this scenario for my session:
User requests the login-page
MagicFilter sets a cookie with a JSESSIONID etc
other filters do some work ...
Java Spring MVC, so as last step before the user sees the LoginView i have access to stuff in my LoginController. Here i .invalidate() the session right before i return the view.
So basically the user never has a real and valid session-ID while at the login-page. Only after he logs in the MagicFilter assigns another session-ID which will then be sticked to, as i only invalide() the session-ID in my LoginController.
But this feels very rough and i kind of had to "hack" around the automatic process of the MagicFilter.
Can anyone see if this should be safe in terms of session fixation or not?
We have a web application that's built on top of Play framework 1. The current version of Play is 1.2.7. It's running on top on Ubuntu 12.04 in an Amazon EC2 instance.
Recently we experienced a peculiar and very worrying behaviour on our test server. There were only a few people using the system: a few developers and a few testers. What happened was that the session cookie of one user was given to two other users. Suppose you have users A, B and C using the system, each logged in as themselves. Suddenly what happens is that all of them seem to be logged in as user A, without any of them doing anything special.
Play is managing its own session cookie. Suppose the session cookie name is configured as XYZ_SESSION. When we saw this behaviour, I was able to inspect the session cookies of users A and B (C was in a different organization and site). The session cookie that B had was 100% same as A had. In this application, the session cookie is used to store user name, email address etc. So in practice, user B was suddenly having the same session as user A. I didn't inspect the cookie of user C, but the verbal report was that he suddenly was logged in as user A.
This was actually a second time this behaviour was observed with this application. The previous time was several months ago, and then a cludgy hack was developed to notice the situation and logout the user in question. However, the hack is not very maintainable or scalable, and we want to get rid of it. And preferably find the root cause for the issue.
The authentication logic of the application is implemented using OpenID4Java. However, when this behaviour occurred, all users were already logged in.
We have a theory on the possible cause of this behaviour. In the application, we have a BaseController class that inherits Play's Controller class and that is used as the base class of all controllers. In the BaseController there is some code that gets and puts to the session container. In the code of that class, the session is referred to as just "session", which means the static field in Play's Controller class. The assumption is that Play's enhancer will enhance the reference to use a ThreadLocal field in Scope.Session class. The enhancing would be done by Play's ControllersEnhancer class. However, when inspecting the code of method enhanceThisClass in ControllersEnhancer, it makes use of CtClass/getDeclaredMethods. In the comments for that method it says "The inherited methods are not included." I don't fully understand how enhanceThisClass gets called, so I'm not entirely sure how solid the theory is.
So, our suspicion is that in practice Play skips enhancing the code in this BaseController class, and the static session field in Play's Controller class gets used as plain as it is, and this combined with suitable scheduling of threads will cause the session duplication!
The problem is quite difficult to reproduce and thus we haven't this far conclusively verified that this is the cause for the behaviour we observed.
Anybody have any insights? Have seen similar behaviour with Play? Able to prove the theory right or wrong?
on my work we use play 1.2.7 in a lot of applications. Last month we see the same issue with Play. Two users with the same session. In our case the app is separated in two modules (catalog and checkout), the catalog was using 1.2.7 and the checkout's module 1.2.4. Because the difference between the modules Play! create the same session in each module and given this session to the users. I don't know if your app has the same structure as our, but if yes, i recommend you see this.
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.