I am using ASP.NET forms authentication, is it possible to detect that two of the same login logged in?
I want this to prevent a situation that two users on the same account modify the same thing. so i want to notify the user that another user of the same login name is already inside the system.
I am also using MemberShip model of .net to authenticate if this helps.
Check out this resource. This approach uses the cache to see if the user has made a login request on another machine. I've seen the database also used as well. The main goal is check to see if the user has gone through the login process, and if they have, block the second attempt to login.
Related
I'm just looking into ASP.NET Identity, which seems that it is the most preferable solution for user authentication in ASP.NET apps these days (replacing all the ASP.NET Membership stuff from the past).
I am looking for a solution that would allow to maintain information about anonymous users. Even if the user is not authenticated, we can collect and store most of the profile data that we could store if the user was authenticated.
Even if the user is anonymous, it makes sense to store data like:
shopping cart
comments he's written on the site (so that he can edit them as their creator)
various site preferences (his preferred language, and many other settings)
Then when the user registers, we can offer to copy some of this data into his new user profile (or copy it automatically) depending on what data it is.
Is it possible to achieve this scenario with ASP.NET Identity? It seems that when a user is anonymous in ASP.NET Identity, he cannot have any user profile data.
In order to use the same tables to store all this information as for authenticated users, we might need to create a new user in the system for every new visitor that comes to the site and does some action that requires storing of some user data.
After that, we'd need to pass some cookie identifier to the user, so that we can always connect the data to the user, which can be seen as some form of authentication (although invisible to the actual user). That way, the guest user could actually represent an authenticated user of the system (maybe he'd just have a special role?), even though to his knowledge he's anonymous.
What do you think about this approach? Are there any ways where ASP.NET Identity can help with this?
I found these two related Stack Overflow questions, but I haven't found my answer in them:
Does ASP.NET Identity 2 support anonymous users?
ASP.NET Identity - Anonymous profiles
Edit:
I discovered that there's a mechanism called Anonymous Identification in ASP.NET that seems to solve part of the issue.
https://msdn.microsoft.com/en-us/library/91ka2e6a(v=vs.85).aspx
Maybe it can be somehow integrated with ASP.NET Identity?
Edit2: As noted in the comments, the documentation for Anonymous Identification seems to be outdated and it's quite probable that Microsoft will not be focusing on this much in the future. Solutions that work with ASP.NET Identity or other OWIN-based solutions are preferred.
Asp.Net Identity has no such thing, and it will not be secure identify the anonymous user even through hip IP or a Cookie in his browser, you can ask the user to register with very minimum info or through FB or Twitter to make the registration process as short as possible, and later he can complete his profile, this way you will make sure the data is linked to an actual profile.
ASP.NET profile properties allow your application to track and permanently store user-specific information. For example, users can specify a postal code or a favorite color scheme, and your application can store that information and retrieve it from anywhere in the application. ASP.NET automatically matches the current user — whether the user is anonymous or logged on — with the personal information that is stored for their user account.
Configuring Profile Properties
You will begin by configuring your application to enable profile properties. You will then define the first property that you want to track for each user. This property is named PostalCode and will be tracked for both anonymous and logged-on users.
Source: https://msdn.microsoft.com/en-us/library/taab950e.aspx
I have an existing Wordpress site. The plan is to rebuild the site using the cakePHP framework. Due to time restrictions, I want to replace individual sections of the Wordpress site one at a time. This will mean that both apps will be running side by side for a certain period of time. I need to control access to the cakePHP app using the authorization provided by Wordpress. I'm not sure the best way to go about doing this. I've seen similar questions asked a lot, but I have not yet found a clear solution.
I'm thinking about two approaches:
Plan A:
Configure Cake to look for Wordpress's authorization cookies.
configure Cake to look at Wordpress's database.
Borrow some of Wordpress's authorization logic to teach Cake's Auth component how to authenticate WP users.
Plan B:
set up an authorization API on my Wordpress site.
set up separate auth component in cake.
ping the WP endpoint when a user hits a protected page in the cake app and then manually log in the user. (This would create a second set of auth cookies)
Do either of these sound like the right approach? Is there a better way to do this?
Helpful references: Article about Cake session handling, Cake Auth component documentation, Cake Auth tutorial, brief overview of WP authorization, a more in depth look at wordpress authorization
UPDATE
We've started working on this, and it seems like it will work, but there is a very tricky aspect involving password hashing that warrants its own question. If you're following this thread, you may want to have a look.
I once had a similar situation: Cross framework authentication zend + codeigniter which was few months ago...
Anyways, this is what I will prefer:
set up an authorization API on my Wordpress site.
set up separate auth component in cake.
ping the WP endpoint when a user hits a protected page in the cake app and then manually log in the user. (This would create a second set of auth cookies)
Here, I would suggest a slight change which is do-able.
Make sure, you have a token system of SSO. As in, when person is logged in on Wordpress, set another cookie which will have a token: Token will be username + password (hashed) + secret key, which will be same between Wordpress and CakePHP. On either site, look up for cookie and manually log the user in or just perform a database look up. Hashing is important for that cookie!
However, if the site is using different domains, you might need to re-strategize:
I had different domains once. At the login or unauthorized page, I would ping the other website and bring up their login box. On the other website if the user is logged in, they get post login page and if request URI has sent a token, we perform normal operation and return the authorized token to this (current) domain.
In simple words:
Site A = WordPress & Site B = CakePHP
Site B hits a page where authorization is required then, ping Site A for a login (as it happens when u do Login-with-Facebook sort), which will request via a Token (private key) and REQUEST_URI which will be part of SSO verification table on Site A, if person is already logged in then, Site A will return (via POST) a token, which further will be decrypted via (private key) of Site B and log the user in. Private key of B and A will be same.
Hope this was understandable.
Questions? :)
Answer to your questions in comment:
Ideally, why we use SSO? We use it because of many constraints. For example: You have a database of say... a million row with more than thousand tables, you need to add a module over ur huge app already... so, instead, you will use another database... SSO will return user information, which can further be replicated. For example, when you click on 'Login with Facebook', it returns requested information, like email address, or user's name or even profile picture. Which can further be added to our database... Keeping different databases is strongly recommended :)
To your 2nd and 3rd question: Should both sites reference the same users table in the database? different databases is recommended unless, you are using the same data. Or say changing the software platform.
Should I copy the site-specific user rows into separate user tables for each app? Yes, that should happen automatically. Once you are registered on a main site, nothing happens, things should happen once you are logged in already and then go to site B... Once logged in, user info can always be requested :) That way, new site will have active users ! 2 birds?
Don't complicate (bother) yourself with how what works but, concentrate on how, what is achievable in short period. SSO - Logged in - Restricted page - Look out for log ins - Either login - If already logged in - fetch user info - If user info exists - login via secondary site OR set the new user info . Done!
We developers love flow charts! Don't we? I just created one:
Further answers:
Does the "Fetch User Info" stage mean that we take the user info from the site which is logged in, and create a new user (row) automatically in the other site?
Ideally, you will ask permission from the user before they 'allow' their info to be used but, it varies how your privacy policies are.
In other words, one site handles all the registration/user-creation and the other site just waits for that user to show up and trigger automatic creation. OR at the moment a user registers on the one site, BOTH databases get a user row inserted?
one site handles all the registration/user-creation and the other site just waits for that user to show up and trigger automatic creation. You can have both. Sign up on your website and also a trigger based automatic creation. Depends on your strategy. OR at the moment a user registers on the one site, BOTH databases get a user row inserted? That would be a horrible practice! It will kill the motive of SSO. Motive of SSO is to create an auth family which can be used by users so that they do not have to register every now and then for different websites. update only one database at a time and other when required :)
Questions? :)
I have done this once. I don't have the snippets and/or any references to anything. But thought it might be helpful.
Configure WP and CakePHP both to use same session, you can do this by session id and session name,
When User registers for your website, register them using both WP and CakePHP,
Choose one framework that will handle login view from the front end. I had chosen CakePHP as I was more proficient with it, once the login is successful locate the same user in other framework's DB and authenticate the user using their authentication system.
Hope this helps !!!
Suggestions:
If you are building a closed system, meaning you have to be signed in to access anything useful in the site, then you can use CAS . I know it's used by mainly universities, but for closed systems it works.
( If you need to handle anonymous users the suggestions below might help)
Keep it simple and, similar to Part A of your plan, have a cookie ( visible by both cake and wordpress ) that simply states if a user is logged in. The cookie should be created/checked by both cake and WP. Cake does not need to look at WP's DB. The cookie can have information on how the users in each system are mapped.
Have a central login screen, this is similar to what CAS does. But please build your own. CAS does not handle anonymous users. I am currently creating a central login screen for work. It's simple. The central login screen will handle all authentication and create the cookie visible to both WP and cake. This would mean that the login link for WP and cake will redirect a user to a common page. The link will need to provide a callback URL so that after the user authenticates successfully, he is redirected back to the original service. You will need to decide on a central DB for user authentication.
The cookie approach has following bonus:
It's a lightweight solution and can be wrapped with an on/off switch. In WP, simply wrap the cookie logic with a wp_options value.
You can use WP's and cake's authentication system. no need to work with API's and/or sessions. No need to couple applications by looking at each other's DB.
You can keep roles and permissions native, meaning WP will work with it's own roles and permissions system and your cake application will work with it's system.
Adding a new "service" to your platform is as simple as "create/check for a cookie" then use the system out-of-the-box auth system to log the user in.
Single Sign On is as simple as creating a cookie. Single Sign Off would be deleting the cookie.
I can definitely go into more detail on each suggestion if you're interested.
In my appliation,all pages are protected,so they must login to visit the pages.
And the admin of the system can add users.
Now some people told me that I have to prevent people login at the sametime using the same account.
That's to say if there is a user named "John" logined to the system,so other people cannot login with "John" again event he know the password.
Also,if one user find that someone have logined use the account he wanted,he can make the former user offline. If so I have to judge if the current user have been offed ornot in each page. This is not a work can be done easily.
I wonder if this is necessary?
Since I found so many websites nowdays do not limit this,for exmaple,you can use the same account login your gmail/stackoverflow/yahoo and ect in different machine at the same time.
So Any one can give me a suggestion?
Update:
Now,we use the asp.net's form authenciation,(we do not use the membership yet). And in the t_user table in the databse,we have a column named "isOnline" and "last_login_time".
When user login,we set the "isOnline" to 1,and store the login time.
When another user try to login again,we check the "isOnline" and the time:
if("isOnline"==1 && DateTime.now-LastLogiTIme <40min) // where the 40 min is the form authenaication timeout.
thisAccountHasLogined=true;
But suppose a user logined yet,then he clean the browser cookie,then if he refresh the page,he will be redirected to the login page,but not he can never login again before the form authentication time out because the "isOnline" in the db is 1 and the time span from his login to now does not large than the form timeout.
I am confused.
In some scenarios, I could understand not having multiple logins, but in reality, I have never had to implement it.
Unfortunately, I do not believe there is a standard mechanism for determining if a user is already logged in and this would need to be done by additional logic. In our application, we use a database for storing session information and using this, it would be a simple process to see if a session already exists within this for the user and not allow login if so.
Update
I was interested in this myself and found this;
http://msdn.microsoft.com/en-us/library/system.web.security.membershipusercollection.aspx
and this
http://msdn.microsoft.com/en-us/library/system.web.security.membershipuser.aspx
Using those, it may be possible to get this information with the .IsOnline() However, this does make the assumption you are using standard asp.net membership
the table where you store user name and password add a column status
when a user attempt to login update status to "Online" when logout update status "Logout"
During login check status, if status is online , terminate process. This may be an approch to implement this, hope it will help you
Im building an ASP website with user login. Does any one knows what is the best and must secure way to make login page and make pages restricted access? I know some ways and used them for some website but sometimes they were not that secure. There is couple access level for this website. Admin, User, Sales Team, and couple more. Thanks.
you can use session variables to store user level and then on asp code define what user can or can not see.
Or in database, I assume, you have field where level of access is defined as well.
Basically make your security level part of SQL query and show only data user should be able to see.
Basically you should have level of access in database, login page verify credentials and then store user level in session variable.
On any given page, while header loads, ASP retrives session variable and compare it to database.
If user have clearance to see that data he will if not-- display message that he is not authorized or redirect somewhere else where he can be.
Add an include file at the top of your ASP pages which is executed before any of the page's code. This way you can write your security code once, and apply it to all of your pages.
Assuming you are using IIS as your web server, you can let it handle your website security by using the different available authentication methods.
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/9b619620-4f88-488b-8243-e6bc7caf61ad.mspx?mfr=true
http://www.authenticationtutorial.com/tutorial/
Perhaps the best authentication method for you would be Windows Integrated Authentication since it allows you to create groups (or maybe use the existing ones) to give access to certain directories or pages.
I have managed to get all the authentication parts working, however i am confused about setting up registration.
By registration i mean that if the OpenID is not attached to an existing account, then a new account must be created.
Should i simply have it return to a registration page (with from fields for registration) and redirect to a different page if the user is registered?
Is there a way to set up a clean and simple registration flow without signing the user in first (formsauthentication.redirectfromloginpage) then checking if they are new on every page?
Sorry if this is worded badly, like most other things i ask it is difficult to explain!
Thanks
Ideally, no registration is required at all beyond simply an OpenID. Does your site require to know more than a user identifier to provide any functionality at all?
If your site can offer any services to users (even just informational) without asking for more than their identifier, which OpenID supplies, then don't have a registration page at all. This is by far the best for the users and will lower the barrier of entry to new users to your site. Then, when the user accesses a page that offers something that requires the user to give up more information about themselves, stick them with a registration page at that time.
If you must stick up a registration page for all new users, I suggest you do a check every time someone logs in with their OpenID. If you recognize the OpenID Claimed Identifier upon successful login, you just let them through... otherwise you create a database entry for them and redirect them to the registration form.
You can optimize the experience by using OpenID extensions such as Simple Registration or Attribute Exchange so that the user might get a pre-filled out registration form courtesy of the OpenID Provider, further streamlining the registration process.