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.
Related
The situation:
We have a rails application, which runs on 12 different servers (different sets of customers). User credentials are stored in the database of each server. We use Devise for auth.
We have an Android app that, when logging in, you have to select the correct server to connect to.
Requirements:
A centralised login page so users don't need to know which server/url to log in to. This is for the web and android. The user should either:
a) Type their username/email, and be forwarded to the correct server to login.
b) Type their username/email AND password, and be forwarded and logged in to the correct server.
Current Ideas:
Create a NoSQL db table with a list of usernames/emails with the server they need to log in to, the login page can grab the server and forward you on.
Use something like Auth0 to manage user data - however unsure how this would work with our current User credential tables spread across multiple servers.
This is not something I have a huge amount of knowledge on, and looking for criticism of the above ideas/better approaches.
I have ran to the situation where I have to remove Facebook/Google authentication option from my app. So I want to know all the pain during this process.
What about user data ? Is there any possibility to link newly created user with data from previous facebook-login-based user ?
Any other situations which I have to fix ?
Oh my God. I personally do not think that you should do that. Yes, if their users in your application that have logged in with one of these providers, then yes their data possibly could be deleted. I mean if you have stored the access tokens to retrieve information about them, then you will be fine I think. But, if you remove OAuth2.0 then your users will not be able to log in with anything else, such as local authentication, due to the fact that they have not created an account via your local authentication system, as they do not have provided a password for their account. They only gave consent to read or write data about themselves, and you only know their email or username. Last but not least, a move like will definitely harm your User Experience (UX) throughout your application and your marketing as well.
I hope that helps! Try to search about some alternatives to solve your issues.
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.
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.
I'm trying to setup a "private beta" for a site that I'm working on. The site uses open id. I don't want anyone to even browse the pages if they aren't part of the beta. What's the best way to implement this? Any suggestions?
For example:
When the site goes live, users will go to http://www.mydomain.com which will not require them to log in.
For the beta I want to restrict access. Users that go to http://www.mydomain.com will be redirected to a login page. Anyone attempting to access ANY PART OF THE SITE who is not authenticated will be redirected back to the login page.
I could stick [Authorize] attributes all over my controller actions, but that seems stupid.
If you're using ASP.NET MVC, it comes with authentication/authorization out of the box. You should be able to use that to setup authentication on your site.
Alternatively you could setup app server settings - IIS lets you setup username/password on a specific site it's serving, regardless of what the actual application may do. If you have access to the app server this might be the best solution.
If you're using IIS6, you can setup authorization easily. Right-click on your site > Properties > Directory Security Tab > Authentication and Access Control > Edit, and enter a username/pwd of your choice. Done.
The real question is how are they being invited to the private beta?
You could setup a password which drops a cookie much like serverfault.com does.
OR
If you know who you are inviting: you could add them to the system before hand using the email/login information that you already know about them (assuming you are inviting them via email)
I have implemented a function in a web application a while ago where we go the possibility to block access to the full website unless the user was an administrator (which in our case meant that the user account was a member of a specific group in Active Directory).
It was based on two things. First, all pages in the web application inherited not directly from the Page class, but from a custom page class in our web application. Second, we had a value like this in the appSettings section of web.config file:
<add key="adminaccessonly" value="0" />
The custom page class would check that value when loading. If it was not 0 it would redirect to a page (that did not inherit the same custom page class, though) informing the user that "the site is not available right now". If the value was 0 the page would load as usual.
In that application we used this to be able to take the site "offline" when we deployed a new version, giving us some time to verify that all was good before we let in the users again.
Best way are invitation system (based on invitation code) or manually confirmation access after create profile in your system. imho
Or you could host the site on a private server, and set up a VPN to use it. Depending on your resources and needs this may be the easiest and most secure way to do what you want without modifying your codebase.
OR alternatively you could use Apache or IIS to force authentication on access to the website directory. Keeping the authentication info in .htaccess for a while.
Even though you use open id authentication, you may still need some form of authorization mechanism. The simplest form would be a user-roles system in your database that assigns different roles to users
In your case, just assign the private_beta role to your private beta invitees and ensure you your authorization mechanism that all users have private_beta privilege before they may continue.
If you don't want to provide authorization for the public site (where everyone can do everything, once authenticated), then, you may only need to do a quick-and-dirty post-processing (for private beta only) on your open_id authenticated users to check them off a short list (which you can store on a text file.