I have basic forms authentication set up and it works just fine locally against IIS express. When I deploy, the sitemap security trimming stops working (menu items are showing that shouldn't be there). If I try and go to one of the nodes that shouldn't be there with a user that does not contain the role required, they get kicked back to the the login screen. Because of that that, I know authentication is working properly.
Another developer I work with has it working just fine locally on his machine as well. The deployed web server is where it no longer works.
I don't believe there is a problem with any of the markup sine it works locally, so I'll withhold from posting the code. Every single example on the web matches up with what I have. The code also resides on a network on with no outside access.
No other posts have been found where someone ran into this issue.
Thanks in advance
After lots of experimenting, we think we narrowed it down. We are forced to use cookie-less session state on this system and that seems to be the problem. Our development machines have a major difference in that they have .net 4.5 installed on them. The production server as well as a few other developers only have .net 4.0 installed. If we allow a cookie, it works just fine. It seems that the paths are not being handled properly on the 4.0 machines in cookie-less session state which breaks the security trimming. Some more testing is needed to verify this. Unfortunately updating the production machine is not an option.
Related
I have made some changes to a view in my ASP.NET MVC3 application, but the changes I have made are not showing up when I test/debug the site within the browser. The changes I am making are simple text amendments to the markup.
I am using the Visual Studio development server for testing the application.
The odd thing is, I have tried publishing these changes to IIS and the changes I have made to the view are working when I test the application using the IIS server.
It is only when testing in the Visual Studio environment that this seems to happen.
Thanks,
A common problem i've run into is when you are not using IE and you close the debug session, but not your browser.
This means that the "IIS/development server" is still running in your system tray, but it is running on the old compiled code, if you hit ctrl + shift + b, you build your entire solution and re-publish your code to your development server. this allows you to hit refresh (F5) in your browser and the changes you've made to the razor view should now be reflected in your browser.
Are you using IE? Maybe deleting the cache or using another browser should work? I've had a lot of problems with that :D
Solution is to use IIS Express. For some reason, the VS development server doesn't recognise changes to code behind - nothing to do with caching on the browser.
However the location of the source code as suggested in other answers is important - it works for me using the c:\windows folder or c:\users\DefaultAppPool - apparently it has something to do with security to ensure.
Only applications running under the 'DefaultAppPool' identity are permitted under IIS. So, for anyone using a VM and mapping the host OS code folder you won't be able to rectify this unless you copy to a local folder in the c:\users\DefaultAppPool folder.
You may also now have difficulties accessing the SQL server database established for the Membership Provider under ASP.NET. For more details on how to fix that, I've posted on my blog.
I'm having some problems running a webservice on my local machine. it's an asp.net webservice, which is using a .Net 4.0 Classic application pool. It works fine on everybody else's machine, and the live servers.
The problem: most request rely on basic authentication, which fails every time, with the correct credentials. Debugging, I can see that the basic authentication part of the header has been removed by something along the chain.
also, Application_BeginRequest in global.asax gets hit twice. Once with the original header (which then appears not hit any of the webservice endpoints) and then with the basicauth-less version.
The issue seems to go away if I switch the app pool to integrated, but unfortunately this isn't an issue as it fails for different reasons then.
I'd welcome any ideas of what is removing the basic auth from the header. I thought perhaps something in my IIS config, but I've reinstalled IIS without any luck.
Well it's fixed now. The noly thing I believe I changed was installing SP1 for visual studio 2010. I'm very doubtful that that was really the source of the problem though
I am developing an intranet ASP.NET web application that's configured to use Integrated Windows Authentication. My web app needs to check user entitlements using LDAP to get user memberships, etc.
The issue I noticed today is that, when I run my web app using IIS, sometimes the LDAP calls fail with strange errors, such as "Unable to contact the server..." ... or "...that domain doesn't exist..." (something along those lines, anyway). However, if I run my web app using Cassini, I don't get those errors.
If IIS is the issue, why would it fail some times and other times not? What does Cassini do different that IIS is not doing?
I'm using IIS 5.1 / Windows XP / Visual Studio 2008
Why is this happening, and how can I fix it?
Probably something to do with the fact that when you're running Cassini, it's your domain account that's querying the LDAP. It is strange that it would work in IIS sometimes though, and not others. Is the server registered on the network? What system account is IIS running under?
#James Johnson: I figured it out thanks to your comment, which got me thinking about my domain account... Finally, I found this post which points out that in order to connect to LDAP one needs to set Impersonation=True in web.config. It was working intermittently this morning, I think, because I was using Firefox instead of IE, which required me to enter my domain username and password.
The other strange thing was that my app worked fine in our development and stage environments even though my web.config is the same for all of them. I suppose the guys in the hosting group have this set at the machine.config level.
I'm developing a web site in a high-security environment. For example, we use CAC cards to authenticate users over SSL.
The site is a mix of VB.NET and C# on .NET 3.5 with some AJAX. The AJAX parts are now calling web services for things like Cascading Drop Down Lists.
We've been running VS2008 configured on our local PCs to use IIS instead of the default server (Cassini). However, some security policies were rolled out to the desktops over the weekend and, suddenly, we're not allowed to run IIS on our PCs anymore.
I already have some of our IT people trying to appeal for waivers for developers. In the meantime, I need to find a way to keep developing.
If I turn off the SSL requirement to the 'secure' part of the application (locally, my PC only) I can serve up some of the pages (using Cassini) when I hit "F5", but pages with web services just bring up "server application unavailable".
I need to be able to add some more functions into the existing web services, among other things, so the ability to single-step through the code is still a necessity.
I'm sure someone who is limited to using Cassini has found a way to Build/Debug pages in VS2008 when webservices are involved.
Thanks in advance.
EDIT: As it turns out, some links had "HTTPS://" hard-coded in them (I inherited these). Changing the link to "~\folder\page.aspx" allowed Cassini to properly serve things up.
Note that using Cassini is the default for VS2k8, even for Web Services. Try starting a new HelloWorld web service project and confirm if you can debug it.
OK So that worked. Then change the debugging options of your real project back to using Cassini rather than IIS. I wouldn't move the project (although backing it up might not be a bad idea) as you might be able to get IIS working again.
EDIT: So your actual problem wasn't to do with web services, just hard-coded URLs. (We have similar problem where much of the site works where ever the root of the website is, but some places, such as "main menu" links, expect the root to be the root of the webserver.)
You proabbly need to contact your IT department and have them open up something on the network so you can call the services - a port on a firewall, for instance.
Is it possible to debug (with VS 2008) a site at my host? I have no particular control of the server, I'm only allowed to upload my website files to the server. I can however upload .pdb files etc.
The reason for me wanting this is because the site works fine on my dev machine, but refuses to show even the first page when deployed on the server (404-error).
Maybe a long-shot, but in my experience the "works-on-my-machine-but-returns-404-on-the-server" problem is often a consequence of that the WebServer Extension "ASP.NET v2.0.50727" is prohibited.
As Ganesh R points out, it may sound like your application never gets startet.
As for the debugging part, I don't think you would be able to pull that off...
Debugging requires that certain debugging components are installed and enabled on the server. This is highly unlikely to be the case on any production hosting platform.
Contact your hosting provider - they will usually be quite willing to help you diagnose the problem you are encountering.