First of all, I'm not familiar with Web development so I might be missing something basic here. Do excuse me if that's really the case.
I'm currently working on a web application (not created by me), which is based on another web app.
Both applications share similar user log in code, but user account info are stored in different databases.
However, after logging in to 1 of the app, the WebSecurity.IsAuthenticated flag is also true on the other app (detected as logged on). Is this behaviour expected?
In case this information is of any use..
1 of the app uses ASP.NET development server while the other uses ISS express.
This is not exactly an answer to my initial question.
That has been answered by #Esa in the comment above --> Setting machine key to Web.Config.
The following is an answer to the problem I mentioned in the comment.
(Should I have posted this in comment instead?)
Both applications were overwriting the same __RequestVerificationToken cookie, which caused error "The anti-forgery token could not be decrypted..." when navigating.
This is because both applications were at the same path of "localhost:xxxxx" and hence detected as the same site. The error can be avoided by changing the virtual path of either application.
For VS, Project properties -> Web (tab) -> Virtual path
Related
We have an asp.net Core application (that is running under .net Framework 4.8) which is deployed withing IIS on a Windows Server 2016 box. This application uses asp.net Core identity framework for roles based access.
Everything works great but when we update the "Site Bindings" (by way of an example config change) within IIS all the connected users get logged out upin the next page request, perhaps the cookie/sessions being reset?!
Whilst this might be the behaviour you expect this was not the behavious we had on a previous "identical" installation which was lost (all data was backed up etc etc but the server host died and we lost the exact settings).
I remember reading a while back (but can't find it now) that the session should actually persist as this allows for load-balancing (which we don't need).
Nothing has changed in the code base for this to now not work so this suggests it's an IIS setting.
Does anyone have a magic change we can make for the connections to persists and our users not to be sent back to the logon page on the asp.net core app?
Thanks.
Jim.
*** update ***
Changing the "Identity" property of the Appl pool entry to System Account seems to allow me to change bindings without the (app pool?) reset.
Somewhat annoyingly, this appears to be the only setting that doesnt reset the user sesions when changing the binding. The obv downside of using this are the security considerations which rule it out!
Anyone with a plan c?
I have a slightly odd situation whereby I have a C# framework 4.6.2 console application to run background tasks that use a shared library for authentication.
Authentication is important here because there are downstream HTTP API dependencies that require a cookie.
The shared authentication project uses FormsAuthentication.Encrypt(ticket) to create a cookie, however, the FormsAuthentication methods require that you have the appropriate setup in a Web.config file.
In my console app, I only have an app.config file and if I add the <authentication> and <machinekey> elements they do not appear to be picked up by FormsAuthentication.
Unfortunately for me, I am unable to make any wholesale changes to this stack as it is a large legacy application with many dependencies, all with an assumption that forms auth will "just work".
Any ideas much appreciated.
So I was mistaken as to the cause of this problem. I can confirm that the forms authentication settings are indeed taken from the app.config, however, the problem was with the default compatibility mode of the machine key element.
After reading this article I realised that the console application was defaulting to Framework20SP1 but the web API at the other end was defaulting to Framework45.
I will leave this answer here in case anyone else has similar issues - if so check the compatibility mode being used in each service. If (like me) you need to override the default so that they match between services then simply add the compatibilityMode="Framework45" attribute to the <machineKey> element.
We have a public website that is already exposed to the outside, although in reality there's really nothing there. Simply default.htm file with "Coming Soon" text in it. (http://vensuresoftware.com/)
We also have a WebAPI we've put together that we want to add to this website. When I publish locally to my IIS6, it works no problem. It's accessed as http://localhost/HRConnect/api/Claims just fine. I've used PostMan, a C# client, and Javascript AJAX to access this just fine. I can also load it in a browser at that URL, and I get the appropriate default controller and action.
However, I have been totally unable to accomplish this same thing on the website. Ideally I'd like to include it as a Virtual Directory to the http://vensuresoftware.com and access it as http://vensuresoftware.com/HRConnect/api/Claims but I've had zero luck doing so.
I have tried to add it as a Virtual Directory as well as an Application under that specific website, but when I access the URL, all I get is "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."
I've ensure the Application pool is correct, with an appropriate user and the pass through connection test succeeds. But I just cannot access the service or the URL.
Any ideas or suggestions at all on what I can try? I'm not sure what else I can include here. Nothing special in IIS, nothing special in the service really. There's only 3 actions in it. As I said, it all works beautifully locally, under localhost though.
IIS 7 doesn't have built-in support for extensionless URLs which causes a lot of headaches trying to get MVC and Web API apps to run. I've gotten it to work using both these options. Pick the one that applies to you.
Install this IIS patch which allows IIS 7 to handle extensionless URLs.
If the patch isn't an option because you're worried about breaking other sites on the server, you can make the Web.config adjustment found in this answer. You'll have to do this for every MVC/Web API app you have running on the server.
I've just finished developing the core features of my site, and have now uploaded it to a host to test.
Unfortunately, I get the following error:
Security Exception
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.
After tedious searching, I realised that it's because I developed in a full trust environment, and my stubborn host will only allow medium trust.
When I set medium trust in web.config, the debugger doesn't show what exactly needs the full trust environment.
Is there any way to clearly check this, or somehow force the site to co-operate?
I am using MVC with FormsAuthentication, Code-First Databasing, etc.
After a LOT of trial and error, I have found the error.
Microsoft's SignalR requires full trust, and there is no way around it.
Disabling that fixes the issue.
Edit
It also seems that any library that will help the site out in the long run is out. If anyone is getting this error, simply disable (comment out) any tertiary library you use BEFORE altering your core code.
Breakpoints do not help at all, as after disabling SignalR, I had an error on a certain page. Setting a breakpoint didnt stop the code in the error event, as it turns out the Security Exception is thrown somewhere deep inside C#, and not brought to the top.
You have two options
You could have two web.config files, one for debugging and one for publishing and testing under an environment that is as close as posible as your hosting environment.
Another option could be two have a single config file with the medium trust set, and use logging to a file/event logger to allow you to debug
I have to deal with a legacy asp.net mvc web app (.net 4). It uses some customized routing, which works fine when I use visual studio 2010's development server. However, when I use iis instead (during debugging) it does not seem to work (never used iis during debugging before).
The answer provided here does not seem to help. I already use:
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
Is there any other reason why the routing may not work? Thanks!
A generic post, unfortunately Internet Information System can create a slew of configuration issues. This is quite possibly it's largest pitfall. Is when you launch it on a Deployment Server, Local Server, or a Production Server the outcome may never appear to be the same.
I'll use Internet Information System Six, because it is similar to Seven and Eight but it just lacks certain features.
Inside of your project for ASP.NET MVC Web Application you'll want to right-click your project and select Properties.
You should see a tab that indicates the word: *Web**
Inside this tab towards the bottom you'll want to ensure that Use IIS Web Server is selected.
You'll want to put a Project URL in there.
This field should look like: *http://localhost/ApplicationName*. What your essentially doing here is mapping your project directory for IIS. You see each IIS Site stores a site inside the:
C:\inetpub\wwwroot
That is your Root Site Folder, where IIS will reference all of your Site Components. ** Keep in mind this Virtual Directory in projects is actually different then your IIS Configuration item listed. **
Now you'll want to open Internet Information System, you'll want to setup your File Extensions. So before doing anything in IIS, you'll want to configure your ASP.NET MVC Installer. You need to configure your mappings (ISAPI) to the .mvc extension to aspnet_isapi.dll. This step is required in order for IIS to hand off Routing Request using the .mvc extension to ASP.NET.
From a good blog post he stated:
If you’re planning to use extension-less URLs, you can skip this
section, but it may be useful to read anyways as it has some
information you’ll need to know when setting up extension-less URLs.
Mapping .mvc to ASP.NET
If you plan to use the .mvc URL extension, and are going to deploy to
IIS 6 on a machine that does not have ASP.NET MVC installed, you’ll
need to create this mapping by performing the following steps.
One nice benefit of using the .aspx extension instead of .mvc is that
you don’t have to worry about mapping the .aspx extension. It should
already be mapped assuming you have ASP.NET installed properly on the
machine.
For the rest of you, start by right clicking on the Virtual
Application node (IIS6DemoWeb in this case) and select Properties. You
should see the following dialog.
Make sure your in the Virtual Directory Tab and select Configuration. This will allow changes to the root website. This should bring up your Application Configuration Dialog. That will allow you to physically map your application. Since your using .mvc that is what you'll select.
If .mvc isn't found in the list, you can point to the Data Link Library here:
c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll
Now before you run the application you need to update the default routes, that way they look for the proper file extension. In your Global.asax.cs you'll want to ensure your using .mvc extension.
You would implement a method such as:
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default",
"{controller}.mvc/{action}/{id}",
new { action = "Index", id = "" }
);
routes.MapRoute(
"Root",
"",
new { controller = "Home", action = "Index", id = "" }
);
}
That should allow the site to properly display. This is a very, very generic and broad example. But hopefully this points you in a good direction.
Update:
When utilizing Internet Information System Seven you have to be aware of the following:
Site Configuration
Application Pool
Database Configuration
Those three items are common culprits to incorrect configuration.
A really wonderful blog can be found here:
Another nice article can be found here:
However, this article should hit the nail directly on the head for you:
As I stated the above detail should resolve your issue. But, with the introduction of IIS 7 they have two completely different methods to allow request: Integrated and Classic.
The major difference is Integrated will perform better and includes more features. Where Classic is designed for backwards compatibility. Your route request processing method is determined by your Application Pool. With this incorrectly configured; it won't work.
Launch the Internet Information Services Manager
In the Connections window, select an application
In the Actions window, click the Basic Settings link to open the Edit Application dialog box
Take note of the Application pool selected.
By default, IIS is configured to support two application pools:
DefaultAppPool and Classic .NET AppPool. If DefaultAppPool is
selected, then your application is running in integrated request
processing mode. If Classic .NET AppPool is selected, your application
is running in classic request processing mode.
From within that box you'll be able to modify the processing mode within an "Edit Application Dialog Box".
Hopefully this additional information better assist you for your goal. The first two blogs are a avoiding IIS, where the third one focuses specifically on IIS 7. If you have any questions let me know.