I've got an ASP.NET site. I want to forbid user to log in with the same login from two computers. If someone is logged in and somebody else wants to log in with the same login it should show him a message that this user is already logged in. I don't have any Forms Authentication or something like that. On button "LOG IN" I just connect to the database and check if user and password are valid.
I thought that when user is logged in, I would update his status in database and when somebody else will try to log in, I will check in database if this user is already logged, but it isn't good idea, because when user doesn't click button "LOG OUT", it will not update his status in database that he's inactive.
Is there any other way to do this without Forms Authentication and something like that?
There is no perfect solution
You can't reliably solve this problem, but you can come close. There will be edge cases where a legitimate user will be frustrated by this restriction.
What you can do
The ASP.Net membership provider keeps track of the last time that a given user was seen, meaning the last time they were logged in and accessed a page. You can follow a similar strategy, also noting the IP address of the user and perhaps the user agent of the browser.
If you see two different IP addresses and/or user agents for the same login credentials within a short window (say, 20 minutes) you can assume they are most likely from different devices.
Be aware
As I said, there are edge cases where you will be wrong. For example, someone on a mobile device will frequently get a new IP address.
Honestly, it would be easier to let Microsoft take care of the details with the forms authentication but here is how I would do it if I was "challenged" to not use forms authentication. (There are other ways, this is just one that I like).
On log in I would create session cookie for the user (say 10 mins), this cookie would contain an id to a table where I would store their userid, the login time, and the ip they referenced from. I would include this information in the cookie too (with a simple encryption), on every page load I would update the cookie to last an additional 10 mins and check the credentials against the database. This means the session would time out if the user did not access the web site every ten mins. This would also allow you to know when the user was logging in from another location.
Side note: Almost all of the above is taken care of for you if you use a custom authentication for windows forms. Using the windows forms authentication means you don't have to worry about the time out and cookie management.
You could have the user last_activity_time file in your database which is updated whenever a logged in user access any of your page. You can now have a window e.g. 30 mins (a period of time when it is valid that the user is logged) comparing the last_activity_time with the current time, if the time difference if greater than the required window (30 mins), you consider the user is inactive
Related
I have a very strange requirement and I want to know how
feasible its.
A customer wants a web application, but in it, they want the administrator to be able of:
Create users in Active Directory
2. Be able to change users password or generate random ones and then it must be changed on AD
3. Be able to change minimum login length and maximum login length for new users in AD.
4. Be able to change password complexity in case users change their password, then the web app should show an error message.
Update 1. More questions About Nr 3. Users want to be able to define if login length is between 5 and 10 characters from the web application, is there an API for this on AD?, I am not an AD expert so I dont even know if AD has the option to configure the username length.
More questions
5. Can I with AD API, view and audit log?, when were users authenticated, was login succesfull or failed?
6. Configure the number of attempts before the account is locked? and alert and administrator when an account is locked due to # of failed attempts.
7. This one is like a stupid question, can I make a functionality for users to recover their passwords via email? (literally they asked me that), but if the account is locked they wont be able to access their email either, lol
8. Configure via API when the user must change password or when it expirtes
9.
Completely feasible
Completely feasible
Not sure what this is - can you provide an example? Still don't understand.
You can enforce complexity on password change programmatically. If you want to dynamically change the password policy, this is also possible.
You would need to consume the event log on each domain controller. You could look at something like Windows Event Forwarding to aggregate the data in one place.
Configure, yes you can do this programmatically. Alert, you'd need to build a trigger on the appropriate event ID.
Passwords are stored in an irreversible (and inaccessible) manner in AD.
Yes you can configure when they need to change it, but, you can't alter the expiration date.
I have a web application which is largely a content system - that is, it displays help for another system. It doesn't matter who views it. However, there is a list of users I would like to display, and also provide a way to edit the list. On that one page I want to detect the user's Active Directory information, and if the user is in the list of users authorized to change the data, then display an edit icon button to provide a means of editing some element. I do not need nor want Windows Authentication determining whether the user can get to the page, only to discobver the user's logon creds.
In short, I want this:
// Get the user's creds
// Is user a page editor?
if (IsPageEditor(UserCreds))
{
// put icon buttons for editing
}
else
{
// don't put icon button there
}
First of course is, getting the user credentials. I should add that this will all be on a private company intranet, and every user will be signed into the network.
I do not need nor want Windows Authentication determining whether the user can get to the page, only to discobver the user's logon creds.
Why not? Windows Authentication is the obvious, secure way to discover the Windows identity of the connected user.
Any other mechanism is insecure, i.e. a user who is not authorized to edit could spoof an authorized user's identity. Using Windows Authentication doesn't preclude you from allowing any user to access the application.
My understanding of setting Windows.Authentication ON is that it will challenge the user to give user name and password before allowing to view the page
No, this isn't correct. If the server is in the same domain as the client, and the server is configured to allow all domain users to connect, there doesn't need to be a prompt to the end user.
Our trouble ticket system "knows" who we are when we access the page -- it must be getting this information from Active Directory, from the current logged in user.
Probably it is using Windows authentication. Try examining the HTTP flow between the browser and your trouble ticket system with a tool such as Fiddler: you'll probably see an authentication challenge/response.
To get the current logged in user you need to call WindowsIdentity.GetCurrent();
From there you can do a lot of things depending on your requirement, get users groups, get OU information etc. For a full AD wrapper I have a full article here
http://macaalay.com/2010/06/28/active-directory-c/
I understand that when a user logs in to MVC webapp (when runtime executes FormsAuthentication.SignIn(..)), that user receiver a cookie and continues to work with the site with that cookie.
However the user can login again, from incognito window or another PC and get access to the site from both places simultaneously. I would like to prevent him from doing that.
I believe that the solution of this issue lies somewhere close, however nethier googling nor digging into MVC Forms Authentication classes provided me nothing I could work with.
So how do I forcibly sign off the last user login info (I believe it is a cookie stored inside a web server, I might be wrong) when that user successefully attempts to login in somewhere new place?
You need to implement
Application_AuthenticateRequest
in your global.asax file an validate that the user identity is still correct. e.g. you need to keep track of all session related to the user and which clients he used. You can then respond with a cookie reset in the mentioned method, if you want to sign out the user.
The only way you can do that, is by storing the user login in information in a table. So when the user tries to log in again, you can verify weather he is logged in some where else by quering the table. Once the user logs out, delete rows from the table.
Remember you would not be able to do anything with the help of cookies. Cookies will just contain form authentication ticket, which would be used by authentication module to verify whether the coming request is authenticated or not. And since the calls are stateless you can not decided anything just by looking at the cookie
is there a way to redirect a user when there are n people/sessions on a site. I have a requirement to redirect to a 'sorry we are busy, please try later' page if there are too many people currently engaging the site (this is to stop flooding a live business service that is behind the webpages). The ideal is that only new users (users not already logged in) are shown this page. I was going to just count concurrent logins but wondered if there was a better way to count current activity rather than login status being that most users might stay logged in for a while.
thanks in advance.
There are several ways you could do this.
I think the most obvious way would be to do this in IIS. If you are using IIS 6.0, you can do this by going into the website properties, go to the performance tab and change the connection limit to what you require. You can then customise the default IIS error message (I think this is classified as code 500).
Alternatively, you could do something when the user attempts to login to the website. You would need to have a mechanism to keeping track how many users are connected, one way of doing this might be to use the Membership provider, which allows you to track (count) how many users are currently logged in (presumably through some basic math on the timestamp values in the membership tables).
Finally, you could probably at a push do something with Ajax to keep telling the server that the a user is "still online", but I would do this as a last resort.
My money would be on the first option.
Hope this helps
I have to design a CMS where a set of credentials can only be used once. So if a user has logged in from his computer, no-one can login with his credentials from another location until that user logs out.
Now using the asp.net membership provider out the box, the IsOnline method returns a boolean that reflects the timeout window vs. the last activity date. This is not a viable option for me, because if the user just closes the browser after logging in, IsOnline will still be true. But his session will be destroyed(assuming he's not using Remember Me) so if he tries to log in somewhere else it will say "Sorry you still logged in".
Are there any hard and fast options for doing this..?
I was thinking of forcing the users to be "Remembered" so when he logs in a boolean "IsReallyOnline" will be set to true and vice versa when he logs out.. Although this option has it's limitations, (people turn off cookies, not logging out and closing the browser then sum1 else comes and browser to the site and he's logged in etc....) it seems like the most viable for now?
Any suggestions?
Thanks in advance
You are really asking for something that is outside of the remit of the web. The HTTP protocol is by definition stateless, meaning that at any one time; a server never need know if a client still exists. The newer/older implementations of web server programming languages (e.g. php / asp.net mvc) for the most part shy away from storing any state about connected/active clients.
Some things to ask yourself include:
How long may a user be 'active' on a page without causing a postback? Javascript based pages may allow for a user to interactively be using a page for quite some time before any kind of postback happens.
Will the users be going through a proxy or caching server? Multiple requests from 'different' users may come from the same machine in this case.
Will your application be running on one machine only, or maybe a server farm? You'll need to ensure that load balancing (for example) doesn't punt different users onto different servers allowing multiple logins.
How about a user legitimately using two different browsers on the same machine? Is this to be allowed?
One might suggest your problem here stems from trying to use the wrong technology given your requirements? Maybe writing a client application which uses direct connection to your servers would be more 'secure'? (Yes I understand this is huge hassles but if your one user / one logon requirement is absolute maybe you could explore this avenue?)
Oh alright, a web solution
For a http centric solution you could try a javascript timer making a request to your server every X seconds to indicate that the session is still active. As long as the browser is open and the network connection valid you should be getting these 'pings'. The session is kept open by the cookie passed by the httprequest.
You'll be able to code the 'ping' page to store the user details into either the application object or some membership provider of your choice then interrogate this provider whenever a client attempts to log in.
This will require a relatively short time-out on a session or some other mechanism to ensure that a crashed browser doesn't lock your legitimate user out for too long.
Please note: This will fail horribly if the user doesn't have javascript turned on (Don't assume that they will have!)
Fast Option: Store IsOnline as a session.
Check if session is true, then allow. If not, don't allow.
If user closes browser, he will be logged outas its in a session.