We are using anonymous identification in asp.net. Anonymous identification creates cookie whenever user lands on our application first time. according to the value of cookie we identify our user and made our business check whenever user lands on our application. It works fine with one cookie/user/anonymous user at a time.
Now i want two parallel anonymous user in one browser at a time. Can you please help me regarding this? How can i do that in Asp.NET MVC? How will I manage two cookies at a time?
let suppose two tabs are open in browser so it mean two user are present. How will system behave when user enters same URL in 3rd tab?
Note: This is a bad idea, and users sharing a browser session seems really fishy to me. You could also use Chrome named users or an incognito session, or different browsers. However, I will present a solution assuming that the strange requirement stands.
You are looking for cookieless sessions. Add this to your web.config in the system.web section:
<sessionState cookieless="UseUri" regenerateExpiredSessionId="true" />
Note that you may find that this is not officially supported anymore in MVC, but does work in many cases. It worked in my simple test.
This will use the URL as the session identifier with each user getting a unique session upon hitting the site without a session in the URL. This is not secure at all because users like to share links and in this case they will be sharing a link to their session.
For your case, this may be sufficient.
More info here.
Related
I have a single solution with multiple C# ASP.NET Web Forms projects. I want a way to identify a given browser so that each website can identifier that same browser. I need to do this from the C# Code-Behind code (not with the client code, like JavaScript). I also cannot use the Session because it isn't shared across websites. I don't think cookies are either.
For example, if a user logs onto Website1 and then logs onto Website2 with the same browser on the same computer, I want to be able to identify that. But if a user logs onto Website1 with Chrome and then Website1 with FireFox (regardless of whether it's on the same computer or not), I want to detect that as well.
If it makes any difference, I am using Azure to publish my web projects. So all websites will have similar domains (eg website1.azurewebsites.net and website2.azurewebsites.net).
If you want to track someone using the same browser on the same computer then use a cookie. If the websites have different domains you'll need to be clever because modern browsers have a lot of protection against what they see as tracking cookies. One option is using a hidden interstitial page as described here.
Your second scenario, a user accessing same site with different browsers, I suggest storing the user agent string (one of the request headers) and adding this to a login audit so you can build up a collection of different user agents used by a given user. There are libraries available for parsing user agent strings and extracting name, version, engine etc.
Between these two techniques and a bit of business logic you should get what you need. If you would like me to clarify any of this, let me know and I'll provide more detail.
I have an application that uses APS.NET as the middle tier. One of the features for administrators is to allow them to popup another browser window logged in as a non-admin user, so they can provide support.
I use a javascript function "openWindowWithPost." The application takes credentials from a DB and forces a login so the support staff does not need to know the user credentials. Unfortunately when it does that the original session is reused and hence all of their application variables are shared, causing havoc with the original Admin login.
What I would like the ability to do is to force a second browser window to popup and when it talks to IIS have it create a new session and keep the original one active. Is this possible? If so where can I find how to do this?
From your post, it looks like you are using the Session object in ASP.Net to store data.
By default the Session ID is stored by the browser in a cookie. See MSDN
for a description of how it works. You could setup your application to use query strings to store the session id, but that is really old fashion and can become messy and hard to deal with.
Your best bet is to find a solution at the browser level. For example, Firefox has an extension called Multifox that would do what you want. Other browsers have similar extensions.
i'm currently developing an intranet web app, with a homepage and several departmental pages, the web app is merely for viewing information so everyone will have the same privileges. i've reached a point that i must worry about the app's access and authentication, my company has an active directory with several groups that i can use, after searching for a while i got the following questions:
in the webconfig file, i forced windows authentication and blocked users that are not authenticated (deny users = ?)
i saw somewhere that i need several webconfig files, one for each page, is that so? how do it make each page connect to the corresponding webconfig?
after looking at some examples i can't figure out my AD connection string (i'm currently on a development machine), our AD groups are on our domain controller, the physical location is "DCserver.company_name.local\city folder\groups"
do i need to create a login page? i mean doesn't that kinda go against the point of having windows authentication?
i don't need to manage anything within the AD, i simply want to read the groups and ensure that, for example, the marketing people only have access to the homepage and the marketing departmental page
as i've mentioned up there, there will be no special special privileges, the user from, for example, marketing will be able to click everything within his departmental page
i'm sorry for all the questions, but i'm relatively new to c# and .net development
Following are the answers to your latest set of questions:
-In the webconfig can i specify the groups that have access to each departmental page as well as the homepage? kinda like the following code, if so, i need my ldap connection string to be placed before assigning which groups have access to which page, right?
[Dipra] You are probably better off doing the authentication without using the roles in web.config, as this will also require the roles to be defined. We are talking about AD groups here, of which users will be a part. So, in the Page_Load(), simply call the authentication method, probably passing the username and the AD group allowed access to the page as parameters. If you want to make your solution configurable, store the allowed AD group for a particular page as 'keys' in your web.config and then read them in your code. Pass the group to your authentication method along with the username.
-when a user opens the web site, he will be prompted to insert his windows credentials, this is automatic, right? he will then be able to see the homepage and then go to his departmental page, right?
[Dipra] Yes, this is automatic. No separate code required for this. He can go to whichever page he wants, provided he is authenticated.
-if i understood correctly, in every page_load event i need to do a search taking the user's name and checking to which groups he belongs to, is that right?
[Dipra] Yes, you need to do that check in every Page_Load() method. As an approach, you can try getting all the groups of which the user is a part, and then check whether the allowed AD group for that page is one of those groups. If it is, the user can be authenticated.
-i the above is true, and now i'm gonna explain the navigation of the page 'cause i think that messing with the page_load might bring me some issues
will the check to see to which groups the user belongs to occur with every page load? won't that make the app slow?
[Dipra] Every server side control, e.g asp buttons, will cause a postback. To ensure the authentication code in Page_Load() doesn't run every time a postback happens on the page, enclose that bit in if(!Page.IsPostBack) {}. This means any code within this block will run when the page is not being 'posted back', i.e., being rendered for the first time. Any subsequent postbacks from server side controls on this page will ignore the code inside this block.
-finally, to check the membership of each user i need a similar code to the second answer on this The Link that Dipra posted i pasted below but in c#, right?
[Dipra] You can refer to the accepted answer on the above post, probably with a couple of tweaks of your own. It's already in C#.
Yes, your web.config would be like what you said.
You don't need to 'grant' access to specific groups for pages. In the web.config, store the groups allowed access to specific pages as keys and read the configuration in your code like this. For example, if you have a key named 'Marketing', then you can store the name of the corresponding AD group, which is allowed access to Marketing pages in the value field. Yes, once you have got it working for one page, others will be easier.
No, the authentication method that I talked about is a custom method you will write for yourself, which will use logic similar to the one in the link I had posted.
The entire authentication code should be enclosed in a try...catch block. If there are issues while doing the authentication against your AD (for e.g., connection problems), then your code will throw an exception. Catch (and ideally log) the exception and redirect the user to an error page, probably saying there were some problems which prevented authentication. You should not be granting access to the user in such a scenario.
I have two website consider it as website1 and website2.
In website2 there is a login page .When a user click on the login button it will call a HTTPhandler in website1 to authenticate user.On successful authentication user information will be stored in a Session variable from handler.
Then it will redirect to a page page1.aspx in website1.But the previously set session is not available in the page1.aspx .What will be the issue?
I checked the session id in first request(when calling handler in website 1 from webiste 2) and Second request( redirecting to the page1.aspx from the handler) the session id is different.
How can i retain the session data?
You need to store session data in another process shared to both web site.
You can do it intwo different ways:
Configure an SQL server
Configure SessionState service, a Windows service used to share informations.
In both cases you have to change both web.config files to support the new session mode.
I.e. to use SQL:
Prepare a database (from command prompt):
cd \Windows\Microsoft.NET\Framework\v4.0.30319
aspnet_regsql.exe -ssadd -E -S localhost\sqlexpress
Modify web config as following:
<sessionState mode="SQLServer"
sqlConnectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;Initial Catalog=Test" allowCustomSqlDatabase="true"/>
You don't need to change your code.
Correct me if I an wrong, AFAIK different domains cannot share a single session. One way to handle this is to carry the data to the other site through cookie [encrypt the values for security], then copy this cookie value to the session in the other site receiving it and destroy the cookie.
And if the sites are in different servers you need to handle the "sticky session" so that servers share the session.
This situation sounds kind of similar to one I have experienced and worked on before, where one web application acts as the login page while another is the actual app where all your work is done. I can describe what I did in the hope that you find it useful.
Like you I had one web app which had the login page (so in your example this would be website2). When the login form submitted I then redirect to a fake Login.aspx page in website1 - this is where we differ I think as I'm not sure of your specific reason for using a HttpHandler.
In my case the website2 Login.aspx page is actually just the way into the web application; it has no markup, just code-behind which will authenticate the user, perform setup (e.g. set session variables) and then redirect to another page such as Homepage.aspx. This particular scenario has worked for me, so maybe your problem revolves around the use of a HttpHandler though I would not be able to tell you why.
In order to retain the same session date across two different servers running ASP.NET web applications you must configure your session state to be managed out of process. This means the actual session state data variables will be stored outside of worker process and in another process that is able to make the session data available to other machines.
To achieve this you can configure your application to use SQL Server to store session state and make it available to multiple servers in your farm. The TechNet article Configure a SQL Server to Maintain Session State (IIS 7) provides details on hor this is done in IIS 7.
If you are using IIS 6 then the steps to configure are somewhat different and I can provide further details on this if needed.
In order for this to work you do need to ensure that both servers are running applications within the same domain, e.g. myapp.com, otherwise the ASP.Net session cookie will not be passed between the two servers. ASP.Net uses the cookie to lookup the session state stored in SQL Server and will therefore not find any matching session if the cookie is not passed on requests between the two servers.
i think IRequiresSessionState will not help because context is different.
once we had the same problem but that was passing asp session varibles to .net. How ever you can do it here also.
on both website create a page setsession.aspx
now if you are on page say web1/page5.aspx and want to go to web2/page3.aspx
you redirect to web1/setsession.aspx?togo1=web2/page3.aspx
in both setsession.aspx logic in to extract sessiondata and place them in querystring
so the web1/setsession will redirect to web2/setsession.aspx?sess1=value1&sess2=value2&togo=page3.aspx
web2/setsession.aspx will check for togo querystring and if found will extract all querystring name and value will set them in session and will then redirect to togo value.
you need to differentiate togo1 and togo carefully.
Session sharing between websites is going to require hand-coding. You could hack the asp.net framework to get this working, but I feel that this is not a clean way of achieving what you set out.
If user authentication is all you are doing from website, is it possible to use alternative? Single Sign On mechanisms will help you out here.
Something like SAMLSSO could help you in this case.
You have two websites which are hosted on different servers, it means you have two different processes running on separate machines, so sessions will be definitely different. Same session can't be shared across processes because by default asp.net support in-memory session.
Here you would need to think about storing sessions information which can be shared between two processes (i.e. out of process). Ideal way to store sessions information in databases. For this you can consider Stefano Altieri code sample above.
I don't think you really want to share session information between two websites at all. From what I can gather from comments, what you're really trying to do is have a user authenticate in one website (give you a username and password which are validated) and then have that "logged in" state transferred to another website which doesn't handle authentication for itself.
What you are describing is the Delegated Authentication model.
In this model, your application hands-off authentication to other systems which it trusts to provide information about users.
There are two well-known protocols which provide this mechanism:
OpenID
This is intended to facilitate users logging in with their own identity providers (Google, Facebook, Microsoft Account). It's a very good choice if you're running a public-facing website, as most users will already have an account they can log in with.
WS-Federation
This is intended to facilitate users logging in with identity providers which are managed by known trusted parties, such as partner organisations.
From version 4.5, the .NET Framework has built-in support for WS-Federation via the Windows Identity Foundation component (and is also available for earlier versions as a separate download). This automates the task of delegating your authentication to an Identity Provider.
It also provides components for you to write your own Identity Provider, should you want to create your own, but you shouldn't have to; you can find various existing implementations to perform this job for you.
The problem you're trying to solve is a very difficult one, especially trying to make it secure enough to be reliable. The good news is that smarter people than you or I have spent years working out very clever ways of doing this. You should use what they have done and not try to cobble together something out of Session state.
In the long-run it's best to let the smarter men do the hard work for you.
I was wondering if anybody could give advice on a secure way to implement a global login. I have an admin page that accesses active directory admin groups after typing in your username and password.
current logged in account (on computer) does not matter
user in web browser goes to web app, redirects to global login page with query string of app name
types user name and password of an account in AD (not necessarily current computers logged in user)
authenticates (looks up user, pass etc and authentication is valid)
redirects back to original web app.
Once redirection happens, how do I securely tell the original web app that this user is ok until the original web session dies?
The way I'm thinking of implementing it:
My original thought was to pass the session ID of original app to the login page as well as the app
name. Store that session in a DB once authentication is checked. Master page of the other app validates on page load that the session ID matches. On session close, remove current session ID from DB.
You cannot depend on sessionID accurately in some cases. SessionID only becomes a constant value after a (any) page makes a request for a session variable, if you dont have Session_Start not defined in global.asax. If you log the user in and the default page does not access session, you will end up with a different session id for the subsequent requests until a request to session is made. Usually it is always constant as there is a default empty session_start event in global.asax.
But similar to your model, you could generate a GUID (or make sure you access session on login/authentication) and store it in the user table with an expiration. Your web sites can check this key and if currently valid, auto sign the user in.
You also cannot depend on session_end event since there is no real accurate way of detecting it (eg: user closing browser). So, you should store this ID with an expiration time along with it, preferably the same as session timeout. Just like session, you will need to extend this, something like a sliding expiration. This way, this id will be expired after a period of inactivity.
also, this Claims-Based Single Sign-On for the Web may be of interest to you.
What you're describing sounds like it would be better implemented using Windows Identity Foundation and Active Directory Federation Services 2.0. I don't know the extent of all your requirements, but it might be valuable to check out what these will give you out of the box.
You could use a cookie. If you pass the name of the application to the login page, you can set that application name to the PATH property of the formsauthentication cookie. By setting the PATH property, you're effectively limiting the readability of the cookie to the pages within that path. Because it's a common login interface, this may require some code being done perhaps in a common page base class that handles the parsing of the cookie information.
You can share authentication tokens between .NET applications, even between .NET CLR's if you want to. I think this will give you the single sign on you're looking for.
At a high level you need to share a machine key between the applications. You can generate the machine key using the key generator app code example found on this link, and providing you then reference the same key in each application the sign on can be shared:
http://msdn.microsoft.com/en-us/library/ms998288.aspx
There are some consideration when looking at things across domains or accross machines/web farms etc, but if all apps are on the same box it's not too hard.
The harder side of things is sharing things like session state which I don't believe can be done accross app pools. (I ended up recreating the session object on the new app manually last time I did it :( but that was between 1.1 and 2.0 apps )
EDIT: I did a rough write up of it last year and was using it as a test for a demo article on my site, might be worth a read through if you want things broken down a bit more (Ignore the unfinished site!):
http://www.dougmcdonald.co.uk/test/html5/v5/articles/2010/05/10/Sharing-forms-authentication-between-applications/