I have two .NET websites, which is setup to share sessions in-between via SQL db.
The website stores and retrieves session as using session("MY_Session").add and Session("MY_Session"). What gets stored is basically a custom class with their username and name.
The parent website is setup in IIS using DefaultAppPool and then the secondary site is setup as virtual directory application in the same pool.
I am not quite sure how it is set up on SQL for the sessions as I did not put it in.
In the web.config for both applications, it is set as follows:
sessionState mode="SQLServer"
sqlConnectionString="server=xxxxx;uid=uuuu;pwd=pppppp;Application Name=NNNNNN"/
Users are claiming that they sometimes open up their browser and go to the site and find that other people's information (from within the same organisation) is appearing...
Anyone able to tell me what I am doing wrong and what to do next please?
This could be a caching issue, if there is a proxy server involved -- make sure any personalised content is correctly flagged so that it is not shared between clients.
A header like this should improve matters:
Cache-Control: private
Related
We currently have 2 separate ASP.Net websites hosted on one of our server. These sites uses StateServer to maintain same session across both sites. We are looking to move these sites to Azure. I was able to upload both sites on Azure without any trouble but I was not able to share the session between both sites. I tried using Azure Cache Service (Preview) to maintain session but for some reason it doesn't work, it always uses different session when I redirect to the second site. I already spent quite a bit of time googling around with no avail.
To get to the bottom of the issue, I now have created 2 test sites and have uploaded it on the Azure. I changed the config to use the Cache Service (Preview) as SessionState but it still doesn't work.
The link to get to the test site is: http://sessiontestsite1.azurewebsites.net/
On the home page, please enter a value in the textbox and click "Update session variable", this will store the text into a session variable. Then, on the top right corner of the page there is a link called "Site2" which will redirect to the second site. I am hoping that second site will be able to access the session variable set in the "Site1" and vice versa. Please note on my local machine I was able to use the same session using StateServer.
I followed this link to configure cache service.
I read somewhere, people were saying that Cache Service cannot be used with Azure Websites but I think those are old posts, as per Scott Gutherie's blog (sorry, StackOverflow doesn't allow me to post more than 2 links) Cache Service can be used with Azure Websites.
Also our requirement is to use these sites as Azure Websites, we do NOT want to use WebRoles or VMs or CloudServices etc.
This is not how session works.
When you put a value in the Session the server assign the client an ID and sends it to the client in a cookie. In ASP.NET it's ASP.NET_SessionId. The client (Browsers) will only send the cookie to the remote address associated with it. If you use Fiddler or browser dev tools you will see the browser sending back the ASP.NET_SessionId cookie to sessionstatesite1 and not to sessionstatesite2 because it has a different hostname.
You can either add the cookie manually (using browser dev tools for example) and test it again.
If you want to use the cache for user session and have the user access the site using 1 URL that get's routed to different Azure Website Instances, that cache will work fine for you. Again you can verify that using multiple ways. Adding the cookie manually above should show you that it's working. If you wanna do it in an end-to-end flow do this:
Create an Azure Website
Scale the site to run on multiple instances
Configure your site to display the Process Id or Instance Id Environment Variable
Configure your site to use caching as you already did before
Store something in session state
log in to kudu (https://<yoursitename>.scm.azurewebsites.net)
Go to process explorer view (https://<yoursitename>.scm.azurewebsites.net/ProcessExplorer) and right click on the w3wp.exe and kill it (you can also verify the PID there)
send a request again from the browser, it will go to a different instance and you can tell by the Process Id, but the session value will still be saved.
Because session sharing in our current setup doesn't work we have decided to use two sites as virtual applications.
We have now created a new website and that website has two sub folders (set as virtual applications). Both sites now sits in theses sub folders. That way session state using cache service works.
Is it possible to share Session state between web applications on separate servers? One of the web sites is using session state to maintain user credentials/info session state, the other is using forms authentication to maintain this information. Without modifications to the website using session storage, is it possible for the website using forms auth to read/access the session state on the other server? If not, which I assume is the answer, would it be possible if they ran on the same server? (i.e. the same app pool)?
Note: Both applications are under the same domain name (one of them will be a sub-domain)
As a note, the reason this is being asked is because a client is requesting a "single sign-on" approach between two websites. We're using forms authentication and the other site (which we cannot modify at this moment) is maintaining credentials/logon information in session
ASP.NET 4
IIS 7.5
Assuming the latter, you could try something like this:
first, make sure all the appliations are running in the same domain. If not, all bets are off. I don't know if there's a simple way to configure the domain property of the session cookie yet, so you may have to do it yourself, by setting the cookie domain property to the domain:
Response.Cookies["ASP.NET_SessionId"].Domain = ".mydomain.com";
you'll need to make sure that each application is configured to use either a common state server, or a db-backed session.
please follow the link : How to share session state across subdomains
We've recently released the latest version of our intranet application, which now uses windows authentication as standard, and needs to be able to connect to a configured SQL server with the end-user's domain credentials.
Lately we've found that on a couple of customer deployments, although IIS can see the user's domain credentials, it will not pass these on to SQL server. Instead, it seems to use the anonymous account. This is in spite of following all the correct steps (changing the directory security to Win Auth, updating Web.Config to use Win Auth and denying anonymous users).
I've been doing a lot of reading that suggests we need to make sure that Kerberos is in place, but I'm not sure (a) how valid this is (i.e. is it really a requirement?) or (b) how to go about investigating if it's set up or how to go about setting it up.
We're in a situation where we need to be able to either configure IIS or the application to work for the customer, or explain to the customer exactly what they need to do to get it working.
We've managed to reproduce this on our internal network with a test SQL server and a developer's IIS box, so we're going to mess around with this set up and see if we can come up with a solution, but if anyone has any bright ideas, I'd be most happy to hear them!
I'd especially like to hear people's thoughts or advice in terms of Kerberos. Is this a requirement, and if it is, how do I outline to customers how it should be configured?
Oh, and I've also seen a couple of people mention the 'classic one-hop rule' for domains and passing windows credentials around, but I don't know how much weight this actually holds?
Thanks!
Matt
This is called the Double-Hop Problem and prohibits the forwarding of user's credentials to third parties. This occurs when they browse from one machine, against a site on another (first hop), and forwarding the credentials to a third machine (second hop).
The problem will not appear if you host IIS and SQL Server on the same machine.
There's alot more technical details published on this at How to use the System.DirectoryServices namespace in ASP.NET, which explains the double-hop issue, and primary and secondary tokens.
To run your application under the user's Active Directory or Windows credentials, ensure these:
the IIS application is set to NOT allow anonymous access
the IIS application uses Integrated Windows authentication
your connection string should have Integrated Security=SSPI to ensure the user's Windows/AD credentials are passed to SQL Server.
i.e. Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
You state you're not sure "how to go about investigating if it's set up or how to go about setting it up".
For this I'd heartily recommend a tool called DelegConfig. It's a very handy app that you can tell you if kerberos is setup properly.
Unzip it into a directory, configure a virtual directory in IIS to point to it. Browse to the main page and you tell it which backend server you want to allow access to (e.g. UNC, SQL, HTTP etc..) and it tell you its setup correctly or not and explain why.
It even has the abilty to recongiure the kerberos to fix the issue if you so desire (although I've not used this - I'd rather reconfiguire it myself to understand what I've done in future)
I realise this comes too late for your particular problem but thought it worth sharing for others that follow - especially the tools ability to explain why delegation is or is not working. I've found it invaluble.
As the title suggests:
What is your opinion on allowing administrators to update the SQL Server Connection string dynamically from the application versus just showing them the connection details in the application?
Because the database connection is so important and on a heavily used system the abrupt change to the connection seems like it could cause problems. However I would think displaying the server and catalog and whether the connection is using SSPI or SQL Auth could be helpful for administrators who don't like playing with .NET config files.
Thoughts?
How are you identifying administrators? Presumably not by looking at the database. Because if you do use the db and then change the database to another server, it's possible they aren't administrators or there's no database, and then bam - they can't get in to fix it.
Typically, I like to do maintenance on this out-of-band (the config file or even in Active Directory, so it's in a centrally administered resource). We also typically have application administrators (roles, maintenance, approvals, workflow-related "administrators") who really are not system administrators in a technical sense. And often, we do not allow system administrators as user, managers or administraors within the application. i.e. I might have a purchase order system administrator who can void a purchase order, but they can't change a database connection and I have a sys admin who can't even create or approve a purchase order, let alone void one, but they can change the database connection in the config or in Active Directory as part of an upgrade or migration.
I agree that a debug page, help page or about page can be useful to show information to both system administrators and application administrators. Whether they should be allowed to change things there really depends.
Sounds like two bad ideas. Allowing changes to connection strings while the app is running is sure to cause disruption (broken connections, data out of sync, and who knows what else). And even displaying connection details to anyone (even admins) seems like a dangerous security hole.
What kind of site do you have where this sort of thing would be necessary?
Requires that your application run in full trust, otherwise it's just using the System.Web.Configuration namespace:
http://www.beansoftware.com/ASP.NET-Tutorials/Modify-Web.Config-Run-Time.aspx
On any change to the web.config the app will recycle, so still isn't something you'd want to in the middle of the day if sales might be in flight.
Also, usually authentication and authorization relies on the database. So if you can't authenticate and authorize, you won't be able to get to the admin page to change the connection string! (Unless your authorization and authentication has nothing in it that touches the database, at least for the admin page your considering)
Personally I don't like letting administrators change ANYTHING on a live site. All configuration changes should go through the same version-controlled, time-stamped, user-attributed, build-system-checked process that source code goes through. Only then can you draw connections "this stopped working at time X because user Y changed configuration A at time B".
An extreme view on the topic I know, but given the huge proportion of downtime that can be traced back to operator error I believe is justified, and I honestly can't understand the fascination people have for being able to edit fragile XML files on live servers where a single extra '>' can bring the entire site down.
I have been tasked with getting a asp.net (vb.net) talking to an analysis services engine on our production servers. The web server is a separate machine from the web server. The web server runs as the IUSR_ user. The application (of course) works on the development machine which has both IIS and Analysis services on it. The problem I see appears to be a permissions error (returned in the browser by the asp.net app):
An existing connection was forcibly closed by the remote host ....
it is described in a similar post here: http://www.mydatabasesupport.com/forums/sqlserver-olap/201903-existing-connection-forcibly-closed-remote-host.html
I am not a system admin, nor am I an expert in analysis services (why have I been tasked with this you ask? because other people haven't been able to get it working and it has fallen on me). Anyway, I could use some help ... I have tried creating and adding the user (IUSR_) to the sql server and added that user to the role. While that worked on my local machine, it did not work in our production environment where the sql and web servers are separate.
tia,
Don
well after some fiddling i came up with something that works. its probably not a huge security concern because this server is not visible to the public internet; it is visible only to a couple iis servers (it is not on our lan) - this is, however, a 'brute-force', non-secure solution (in some environments anyway) ...
ON THE IIS SERVER: added this to the connection string in web config: SSPI=anonymous; this turns on an unauthenticated access request.
ON THE SQL SERVER: in analysis services, right click on the server. under "general" go near the bottom to "Security\RequireClientAuthentication" and change it to False
same page, select "security" on the left (instead of general). Add "ANONYMOUS LOGIN" to the list of users
get out of the server properties. right click on the CubeViewer role in the cube and choose properties. Add ANONYMOUS LOGIN to the list of users.
so, i have unauthenticated access from our iis server to the sql server.
i'd still be interested in seeing a more secure solution - oh, and i forgot to mention, there is no domain ... these are two servers on the same subnet with only regular logins.