To Whom it may concern
I would just like to know is possible to use one user name and it be used by multiple users at the same time on sitefinity without it kicking out a logged on user when another another user logs in using the same user name.
Kind Regards
If the user has a backend role then he will not be able to login concurrently from different machines/browsers. He will have to terminate the existing session before starting a new one.
Frontend users do not have this limitation.
Related
I am using the spring security plugin and thus am able to make use of the method springSecurityService.currentUser to access the current logged in user. However, i assume that obtaining the current user within each controller action and then performing actions based on the returned user is not the recommended best practise.
Examples:
logged in user clicks link to their profile page - controller obtains current user and returns data to populate profile page for this user.
logged in user changes status on profile page - controller obtains current user, from this finds their profile and then updates the status on this profile.
ETC
This should ensure that a user accessing a page is who they say they are - as there is no passing of User Id or other identifying information from a client. However, obtaining the user in each action seems wrong, and i havent seen many examples of code which do this. Should I be using filters to intercept requests or some other flow/practise?
springSecurityService.currentUser exists for that exact purpose. The reason you need to retrieve the current user each time is because controller actions are stateless. Yeah, there's a session at play which maintains some state, but what I mean is that there's no direct transfer of state from one controller action to another. So, it is in fact best practice to obtain the current user each time.
What happens is the client provides a cookie, usually named JSESSIONID, to Grails. Grails then uses that to restore any session data, which essentially leads to springSecurityService.currentUser being able to provide the current user. So while the client does not pass the user ID, it does pass a session ID, which indirectly is identifying information.
Suppose in one application we have interface(UI) to assign roles.
First scenario:
So to say user A who is normal user. And one admin assigns him ADMIN role using UI.
Now when user A logins the application then he can see all the tabs which can be accessed by ADMIN.
Second scenario:
In the same time (when he is logged in and have session with ADMIN role), admin makes user A as normal USER who have normal privileges.
But as he is login as ADMIN so he can access all the admin information for all the tabs as in this session he has ADMIN role.
How I can solve this problem??
The first approach would be to expire any existing user sessions on the on the fly.
the following post describes two alternatives Is it possible to invalidate a spring security session?
A more sophisticated approach would be to flag the use in a list when his authorities changes.
Here is a good example Implementation of singleton thread-safe list
Furthermore, if you add a custom spring security filter which checks if the user is in the list and if necessary reauthenticates the user. I would use the switchuserfilter as a reference implementation. Instead of switching a user, you create a new authentication object and update the SecurityContextHolder.
All the necessary logic should be included in http://docs.spring.io/autorepo/docs/spring-security/3.0.x/apidocs/org/springframework/security/web/authentication/switchuser/SwitchUserFilter.html
I've developed a MVC4-project and deployed it (in bèta version). A visitor must login before he can see most of the website. For login, you are required to register. So far so good.
Now there's some weird dude who is trying to register a 100 times, it seems just to annoy me. How can I prevent this? I already have the following:
I have to manually accept registrations (as admin)
I integrated a captcha
So this dude is locked out from my application anyway, but his registration attempts are stored in my database, so it keeps expanding.
My question is: Is there any way to limit registration actions? Like only one time per hour or something like that?
Kind regards
You can store ip in database after registration for one hour. And before registration check if ip exists in database. Or create application level list of IPs instead of DB.
Setup
I have a Rails application where users register for an account, and a subdomain is created for them. They can then proceed to the subdomain and log in with their credentials. The workflow looks something like this:
User visits base domain fills out a form that with email/username/password and subdomain fields
From the submitted info, the server creates an account in the global/public database. Server then creates a database that will be specific to that particular subdomain/account, and stores the user record in it.
User is redirected to their subdomain, and asked to log in.
(note: to implement the separate "databases", I'm using postgres schemas, but that should be irrelevant.)
The question
My question involves step 3. I would like to redirect the user to their subdomain and log them in automatically instead of asking them to log in. However, I do not want to share a single session across all of the subdomains.
I would like to somehow securely transmit auto login request.
Possible Solution
I have considered using a single-use, random token that I would store in a cookie and in the users table. After the user successfully creates an account, he would be redirected to the subdomain. At that point the token would be consumed/destroyed and the user would be automatically logged in.
I would also need to have a short window for the token to be used before expiring.
Thoughts? Thanks!
I had the same issue, the possible solution you suggest does not work because the session is not shared between subdomains.
I solved it the following way (same idea you propossed, different implementation):
Create a new model (I called it LoginKey) that contains the user_id and a random SHA1 key.
When the user is authenticated at the parent domain (for example: mydomain.com/users/sign_in), a new LoginKey is created and the user is redirected to the corresponding subdomain to an action that I called login_with_key (for example: user_subdomain.mydomain.com/users/login_with_key?key=f6bb001ca50709efb22ba9b897d928086cb5d755322a3278f69be4d4daf54bbb)
Automatically log the user in with the key provided:
key = LoginKey.find_by_login_key(params[:key])
sign_in(key.user) unless key.nil?
Destroy the key:
key.destroy
I didn't like this solution 100%, I tried out a lot of different approaches that do not require a db record to be created, but always faced security concerns, and I think this one is safe.
There's a subset of users which will not have access to the system I'm implementing in the beginning but I need a mechanism for them to capture data for one specific part of the process.
An authorized user creates the original record for a Person with some basic details i.e. First name, last name etc.
I then create a 'DataRequest' record which has a unique guid and the external user is sent an email with a path which is effectively http://sampleapplication/Person/Complete?guid=xxxx
The external user adds additional details like Date of Birth, Eye colour etc, submits and saves to the DB. The DataRequest for that guid is then expired and cannot be accessed again.
The Complete action doesn't have any authorization as these external users do not have user accounts.
My preference is to force these users to use the system but at this stage I'm not sure it's practical.
Is this a bad practice?
Should I be implementing some additional security on this like a one time password / passcode contained in the email? Are there alternative approaches I should consider?
There's nothing wrong with opening up a section of your site to the public. Tons of websites have secured and unsecured sections. However, there's also nothing saying that you have to expose your secure site at all. You can create another site that merely has access to that change those records and make that site alone, public.
As far as securing the information of the user, passcodes by email are the invention of some developer somewhere with limited mental ability or a severe lack of sleep. If the link is only available by email (not discoverable by search engines and not easily guessable), then anyone with the link will also have the passcode, making the passcode to access the link redundant.
You should however log when the email is used to finish the record and then disallow further uses.