I'm having a problem with a MVC (1.0) app that I can't figure out at all. There's two versions of the site (live and UAT) hosted on the same server. For each version of the site, the same code is shared by multiple organisations who each have their own database (MSSQL2005) and a separate web site in IIS (7.5) (pointed to the same code).
The UAT site has an update to the code and the database that is waiting to be deployed to the live site.
One of the customers ("customer A") is getting an error "104: Connection reset by peer" when they try to log in to the UAT site. They can see the login page but when they submit their login details the connection seems to be timing out (the requests seem to take ~130s to complete).
Customer A can log in fine to the live site. The other customers don't have a problem logging into the UAT site or the live site. If I try to log in as customer A, using their login details, it all works fine from within our network, and also from outside our network.
Customer A seems to be using squid as a proxy.
I can't think what the problem could be, and I've run out of ideas of things to test. The fact that I can log in as the customer fine and other customers don't have any issues seems to eliminate the code and database as problems.
What other things could I do to try and isolate the problem?
By dumping out the request data I was able to work out that something (I'm guessing the proxy) was removing the form values from the request. This obviously meant the app didn't work properly.
However, it seems whatever was removing the form data was leaving content-length unchanged, which would explain why the client was timing out waiting for more data and the server thought it was finished.
By using https instead of http (which we were going to do anyway), the request tampering seem to have stopped.
Related
We are attempting to deploy a SignalR site on a Citrix NetScaler, as opposed to the current deployment on a single server. There are three servers in the farm. If you navigate to any single server, SignalR comes up fine. If you go to the NetScaler address, you get this:
WebSocket connection to
'wss://mysite.com/myapp/signalr/connect?transport=webSockets&clientProtocol=1.5&connectionToken=(token_displayed_here)'
failed: Error during WebSocket handshake: net::ERR_CONNECTION_RESET
After this error, there is about a 10-15 second delay, then it starts working. If I attempt to disable websockets as I have read that Netscalers still have issues with them, the error goes away but the delay remains. I believe the delay is caused by it trying to connect with ServerSentEvents and failing that as well. It appears that only long polling may be working over the NetScaler.
We have checked the NetScaler websocket settings, made sure the servers have the correct machine keys, had a backplane set up (tried Redis and an Oracle Nuget package as that's our typical DB), checked the OWIN versions and web.config settings, all of the stuff that Google told me to do that I could find but still get this error and delay. One thing that I did find is that Netscalers have issues with wss, but haven't been able to find anything about how to account for this. Most of the information found was for people using other load balancing technology.
Is using SignalR (or more specifically, WebSockets or ServerSentEvents) with a NetScaler even doable, and if so what could be causing this problem?
We've got a mirrored SQL server 2012 database setup on Azure VM's - two servers plus a witness, all using client certificates, with SQL logins with the same SID set.
When testing our app from a different VM, everything works as expected when we manually failover the database, there's a one second wait and then it continues to operate quite happily.
If we then do another manual failover, ie moving the principal back to the original server, the app errors and throws a 'no such host in known' error. Recycling the app pool fixes the issue, but this clearly isn't workable in production when one of the servers is updated followed by the other at some later point (both are in an availability set).
The host not known error is somewhat baffling as it was communicating with it happily before the initial failover, and will again after the app pool recycle.
Here's the connection string as it is right now, after a lot of faffing around:
"Data Source=server1,1433;Failover Partner=server2,1433;Initial
Catalog=;MultipleActiveResultSets=True;User Id=user;
Password=password; Network=dbmssocn;Connect Timeout=60; async = true;"
providerName="System.Data.SqlClient"
The app is running on .net 4.5.2, so should be up to date with hotfixes, and we're out of ideas after much Googling with Bing.
I've just solved a problem that I had that looks very similar to your problem. I'd get the host not known error whenever the database switched from the first one listed in the web.config file to the failover one. It was fine switching from the failover to the primary.
The problem that I had was that I set up the database mirroring using server names but my web server did not know the database servers by name. Once I fixed this, I was able to get the failover working smoothly both ways.
This is what I think was happening:
I set up the mirroring using the names SQL1 and SQL2 as the principal and mirror servers
I have their ip addresses in my connection string: 10.1.1.5 and 10.1.1.6
The application tries to get to the first server 10.1.1.5 and succeeds and is then told that the mirror server is SQL2
SQL1 goes down and the database is successfully switched to the mirror server.
The web application attempts to connect, fails and determines that it should try the second server.
It tries to connect to SQL2, which it doesn't know, and fails with the message that the host is unknown.
This answer would only apply to your situation if you actually put ip addresses in your web.config and that server1,1433 and server2,1433 were actually masking place-holders for the ip addresses that you actually used.
I haven't really solved the naming issue though. I just added the two database server names to the HOSTS file which isn't an acceptable situation but does prove my theory on what my problem was.
I am researching a setup just like you have and upon reading this and the response by Steve Kaye, I'm wondering if you have SQL browser running. Take a look at this article for how SQL browser comes into play:
http://blogs.msdn.com/b/spike/archive/2010/12/15/running-a-database-mirror-setup-with-the-sqlbrowser-service-off-may-produce-unexpected-results.aspx
I've an ASP .NET MVC4 application that uses SimpleMembership and allows users to sign in with their google accounts.
In order to do that I configured the application's AuthConfig class by uncommenting the OAuthWebSecurity.RegisterGoogleClient(); line to add google as an external login method. I didn't really change much inside the external login methods that already come with the ASP .NET MVC4 Internet Application template.
Problem:
Everything works fine when I run it locally (IIS express) or when I deploy it to a 'test' server (IIS 6.1, accessible on the intranet only). When I click my "sign in with google" button, I'm sent to google's authentication page, whose url looks something like this:
https://accounts.google.com/ServiceLogin?service=lso&passive=12096...(long url)
Alas, when I deploy it to the 'production' server (internet facing) and try to access it via internet, Google authentication stops working: when I click my "sign in with google" I'm being sent to an url that looks like this:
http://MY_APPLICATION_NAME.MY_DOMAIN.com/accounts/o8/ud?openid.claimed_id=http%3A%2F%2Fspecs.openid...(long url)
This url is wrong not only because it has my domain in it (I believe it should be accounts.google.com?), but also because the rest of it is completely different from the url I get when the authentication works.
What I know and have tried:
If I use fiddler, I can see that the application is behaving differently when I'm accessing the application via internet or intranet.
If I access it from within the network, I see I'm making a request to http://MY_APPLICATION_NAME.MY_DOMAIN.com/account/ExternalLogin?returnUrl= and then "Tunnel to www.google.com:443, Tunnel to accounts.google.com:443". This works ok.
If I access it from the internet I see I'm making a request to http://MY_APPLICATION_NAME.MY_DOMAIN.com/account/ExternalLogin?returnUrl= and then another one to http://MY_APPLICATION_NAME.MY_DOMAIN.com/accounts/o8/ud?openid.claimed_id=http%3A%2F%2Fspecs.openid...(long url). This obviously gives a 404.
I might be wrong but I assume that this url is generated by the OAuthWebSecurity.RequestAuthentication(provider, returnUrl). What puzzles me is that it looks like it is requesting the authenticaton to my server instead of accounts.google.com.
My research so far has only brought to me posts/questions/etc. showing how easy it is to use SimpleMembership for external authentication and I can see everyone does it pretty much the same way.
Conclusion:
I believe this probably has something to do with something I must configure on web.config or IIS. I do know that the requests to my application arrive at my DNS server which does a url rewrite and forwards the request to my web server, although I don't know if this is related to the problem.
Does anyone have any idea of what might be wrong or ever had a similar issue? Any help would be appreciated.
EDIT:
I've looked into OpenAuthSecurityManager.cs's source code and although I can't debug it I see the problem might be related to an incorrect HttpContext inside the RequestAuthentication method, due to my reverse proxy settings on IIS?
I ended up with a request to change the IT infrastructure.
OpenAuthSecurityManager.cs was probably getting a wrong HttpContext instance because of the way the requests were being handled by the previous infrastructure (requests arrived at our DNS server and were forwarded to the web service, on a different server inside our network, with UrlRerwrite rules).
It's working now.
i got a little odd situation to develop.
The MVC web system my team has to develop (or project is made with rails), will rely on login/password from another site.
The idea is, the user will have a log-in on the third part site, and somewhere relevant, will exist a link to our site. When the user click on that link, we need receive from the site, some data of the user.
We have no control of the third part server, or direct access to their database. Plus, making then make any change to their application/infrastructure is a BIGDEAL so i am searching for a solution with less impact for then. (Of course they will have do change something but will be a political issue, so the less, the better)
From our viem, we need to be sure that the user really come from the third part site (and only from there), and we not have received a fake message from an attacker.
Their site have an valid SSL certificate working. (no idea if my system will have one (it should))
Not sure if its relevant, but we think that their server is an oracle aplication server, who connect to a oracle server in their internal network.
I first thought in using just SSL, but i not sure how to do it (what i have to check, what i have to change?) and if is safe enought.
My second thought is to use PGP keys, and make then sing and cryptography the data before sending to us, and, the link yo our site, would make a post to a control on our server which would verify and de-crypt the data.
Anyone have any tips/pointers/thoughts that could help me?
If both servers are using SSL, and supposing the server give you at least a json or xml interface, should be ok to simply make a secure request (using, for example, rest-client) and evaluating the response in your server.
Most likely you will want to cache user data on login in your server, and if user/password aren't found, look in the other server - this will reduce the load.
I have an MVC 4 app and am using the default authentication provider. I'm not using persistent cookies.
I don't have any problems in development but when hosted at HostGator, I SOMETIMES get logged off when I try to create a new item (HTTP POST). When this happens, I end up at the log on page like I wasn't authenticated.
HostGator does NOT have the app on multiple web servers so I'm thinking I shouldn't have to worry about machinekey stuff. Am I wrong?
When this happens, I just log in again and create the item again and it will succeed. Once this happens, I can't recreate the issue. I try reopening the browser and even different browsers but creating items will always work. It only seems to happen again if I try much later.
Some additional info, the timeout is set to 2880 (the default for an MVC project), which I know is long but I can't see how it would be related. Still, thought I'd mention it.
So I can't look at IIS logs or event viewer to get any idea what could be happening but I can add more logging to the app. Can anyone provide ideas for what to check or what logging to add to diagnose?
Thanks
EDIT
I realized that I could get to the IIS logs so I compared the POST that succeeded and the one that failed and immediately noticed something.
When I first did the GET to load the Item/Create page/view, the cs-username was populated but when I did the POST to create the item, it was gone. I can see that when I logged in again and was able to successfully create the item, that POST did have the cs-username populated.
Why would it disappear between the GET and the POST? There was a 7 minute delay from the GET to the POST but I can see I logged on 1 minute before the GET so the session was only 8 minutes old when the post happened. I've double checked that I don't have sessionstate explicitly configured so the default should be 20 minutes. I feel like I'm onto something but not sure exactly what.
Might be worth adding Glimpse, although running that on deployed code is kinda risky. It would have the benefit, though, of letting you see what's actually happening on the server. I've never used HostGator, so I can't say for certain, but if they recycle app pools aggressively, that would invalid your login, and explain why the logoff seems to happen randomly.