Can we implement the URL Reqwriting on IIS in shared hosting? - asp.net

Can we implement the URL Re Writing Of IIS level on a shared hosting provider? According to my findings we can't but our project manager said we can.

possible very much using HttpHandlers e.g.
<httpModules>
<add type="URLRewriter.ModuleRewriter, URLRewriter"
name="ModuleRewriter" />
</httpModules>
<httpHandlers>
<add verb="*" path="*.aspx"
type="URLRewriter.RewriterFactoryHandler, URLRewriter" />
</httpHandlers>
More info at this link

Maybe you can use Rewrite feature of IIS 7.5 , please refer following link for guidance
http://www.iis.net/learn/extensions/url-rewrite-module/using-rewrite-maps-in-url-rewrite-module

Related

ServiceStack and SignalR together in same project

It is somewhat trivial question, but I am using SignalR and ServiceStack in single Asp.Net host application.
Means, it is simple Asp.Net blank application, ServiceStack is running on / and it is showing default page using Razor. Running perfectly.
Now, I added SignalR asp.net host. Added startup class and created hub to listen and broadcast chat message.
I have wrote client code in default page only. Now, things are working fine. Means, API and SignalR are both running on local machine.
Now, the question is, is this the right way of doing things? Means, are there two different processes hitting IIS. Or is there any way I can chain process to single process.
Or even part of ServiceStack API I can make real-time.
Please let me know if any further information is required.
Yes its possible, but you cannot run ServiceStack on Owin at the moment (as far as I know)
So you need to run ServiceStack in a specific location.
<location path="ssapi">
<system.web>
<httpHandlers>
<add path="*" type="ServiceStack.HttpHandlerFactory, ServiceStack" verb="*"/>
</httpHandlers>
</system.web>
<system.webServer>
<handlers>
<add path="*" name="ServiceStack.Factory" type="ServiceStack.HttpHandlerFactory, ServiceStack" verb="*" preCondition="integratedMode" resourceType="Unspecified" allowPathInfo="true" />
</handlers>
</system.webServer>
</location>
You may need to remove the handlers for owin/signalr stuff from the location too.
Alternatively you can setup SignalR on a specific path and remove ServiceStack from that path.
i.e
<location path="signalr">
<system.web>
<httpHandlers>
<remove type="ServiceStack.HttpHandlerFactory, ServiceStack" />
</httpHandlers>
</system.web>
<system.webServer>
<handlers>
<remove name="ServiceStack.Factory" />
</handlers>
</system.webServer>
</location>
I know the question focused on SignalR, but ServiceStack added support for Server-Sent Events in v4.0.31. Basicaly, this is a very long-lived HTTP request that streams to the client, allowing for real-time server "push"
This feature is supported by most modern browsers, and polyfills can be used to support IE back to 8. ServiceStack also provides a C# client.

ASP.NET Web API application gives 404 when deployed at IIS 7

I have an ASP.NET Web API which works fine when running on "IIS Express" with localhost:1783
But when I uncross the "Use IIS Express" and then press "Create Virtual Directory"...
...I just get 404 errors:
Any ideas whats wrong? Thanks!
All you really need to add to the web.config file is:
<handlers>
<!-- Your other remove tags-->
<remove name="UrlRoutingModule-4.0"/>
<!-- Your other add tags-->
<add name="UrlRoutingModule-4.0" path="*" verb="*" type="System.Web.Routing.UrlRoutingModule" preCondition=""/>
</handlers>
Note that none of those have a particular order, though you want your removes before your adds.
The reason that we end up getting a 404 is because the Url Routing Module only kicks in for the root of the website in IIS. By adding the module to this application's config, we're having the module to run under this application's path (your subdirectory path), and the routing module kicks in.
For me, in addition to having runAllManagedModulesForAllRequests="true" I also had to edit the "path"
attribute below. Previously my path attribute was "*." which means it only executed on url's containing a dot
character. However, my application's url's don't contain a dot. When I switched path to "*" then it worked.
Here's what I have now:
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true">
<remove name="WebDAVModule"/>
</modules>
<handlers>
<remove name="WebDAV" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
You may need to install Hotfix KB980368.
This article describes a update that enables certain Internet Information Services (IIS) 7.0 or IIS 7.5 handlers to handle requests whose URLs do not end with a period. Specifically, these handlers are mapped to "." request paths. Currently, a handler that is mapped to a "." request path handles only requests whose URLs end with a period. For example, the handler handles only requests whose URLs resemble the following URL:
http://www.example.com/ExampleSite/ExampleFile.
After you apply this update, handlers that are mapped to a "*." request path can handle requests whose URLs end with a period and requests whose URLs do not end with a period. For example, the handler can now handle requests that resemble the following URLs:
http://www.example.com/ExampleSite/ExampleFile
http://www.example.com/ExampleSite/ExampleFile.
After this patch is applied, ASP.NET 4 applications can handle requests for extensionless URLs. Therefore, managed HttpModules that run prior to handler execution will run. In some cases, the HttpModules can return errors for extensionless URLs. For example, an HttpModule that was written to expect only .aspx requests may now return errors when it tries to access the HttpContext.Session property.
This issue can also happen due to the following
1.In the Web.Config
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
2.Make sure the following are available in the bin folder on the server where the Web API is deployed
•System.Net.Http
•System.Net.Http.Formatting
•System.Web.Http.WebHost
•System.Web.Http
These assemblies won't be copied in the bin folder by default if the publish is through Visual Studio because the Web API packages are installed through Nuget in the development machine. Still if you want to achieve these files to be available as part of Visual Studio publish then you need to set CopyLocal to True for these Assemblies
Some people say runAllManagedModulesForAllRequests="true" will have performance issues and MVC routing issues.
They suggest to use the following:
http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html
http://bartwullems.blogspot.com/2012/06/optimize-performance-of-your-web.html
I have been battling this problem for a couple of days trying all kinds of things suggested. My dev machine was working fine, but the new machine I was deploying to was giving me the 404 error.
In IIS manager, I compared the handler mappings on both machines to realize that a lot of handlers were missing. Turns out that ASP.Net 5 was not installed on the machine.
For me, this issue was slightly different than other answers, as I was only receiving 404s on OPTIONS, yet I already had OPTIONS specifically stated in my Integrated Extensionless URL Handler options. Very confusing.
As others have stated, runAllManagedModulesForAllRequests="true" in
the modules node is an easy way to blanket-fix most Web API 404 issues - although I prefer #DavidAndroidDev 's answer which is much less intrusive. But there was something additional in my case.
Unfortunately, I had this set in IIS under Request Filtering in the site:
By adding the following security node to the web.config was necessary to knock that out - full system.webserver included for context:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<remove name="WebDAV" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
<security>
<requestFiltering>
<verbs>
<remove verb="OPTIONS" />
</verbs>
</requestFiltering>
</security>
</system.webServer>
Although it's not the perfect answer for this question, it is the first result for "IIS OPTIONS 404" on Google, so I hope this helps someone out; cost me an hour today.
I had this problem with Blazor and .Net Core and found that incorporating the NavManagers "baseUrl" into my calls to the controller solved the issue regardless of using a Virtual Directory or the root website.
This worked for me!
string baseUrl = NavigationManager.BaseUri.ToString();
NavigationManager.NavigateTo(**baseUrl** + $"api/Download/DownloadFile?FileName="
+ sFilename, true);
I you are using Visual Studio 2012, download and install Update 2 that Microsoft released recently (as of 4/2013).
Visual Studio 2012 Update 2
There are some bug fixes in that update related to the issue.
I had as same problem . afer lot of R&D i found the problem.
but as long as your configuration are finne mean that aspnet 64 bit and the IIS well then
the only problem i saw is the path " web api taking the local directiry path" so that you need to avid it. by like this.. ~../../../api/products/
thank you very much for posting the problem. i leanred alot abt iis and other setting in config file.
For me I received a 404 error on my websites NOT using IIS Express (using Local IIS) while running an application that WAS using IIS Express. If I would close the browser that was used to run IIS Express, then the 404 would go away. For me I had my IIS Express project calling into Local IIS services, so I converted the IIS Express project to use Local IIS and then everything worked. It seems that you can't run both a non-IIS Express and Local IIS website at the same time for some reason.
Spend a whole week, after all the following setting worked ! and finally saved.
Removing the UrlScan from ISAPI fileters in IIS fixes the problem in our case

Deploying Castle Monorail on Windows Server 2003

I'm deploying a castle monorail web application to Windows Server 2003.
I've already set the httphandler mapping in web.config as follows :
<httpHandlers>
<add verb="*" path="*.castle" type="Castle.MonoRail.Framework.MonoRailHttpHandlerFactory, Castle.MonoRail.Framework" />
</httpHandlers>
<system.webServer>
<handlers>
<add name="castle page" path="*.castle" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
</handlers>
</system.webServer>
But whenever I tried to access http://localhost/app/Home/Index.castle the web server always returns HTTP 404 Not Found. It looks like the mapping is not handled by ASP.NET engine, like I've been missing a step or two in the configuration. Any solution?
Because you are using IIS 6.0 the <system.webServer> section is ignored and you need to associate the .castle extension with the ASP.NET ISAPI filter in the IIS control panel.
Phil Haack blogged about how to achieve this with ASP.NET MVC and the .mvc extension. For you this would be the .castle extension:

How to do Forms Authentication on purely HTML pages using ASP.NET?

I am using forms authentication in IIS7 to password-protect a dev site, but the authentication seems to get by-passed when the site contains only static HTML files + login.aspx + web.config.
When I renamed the files to .aspx, I am prompted with the login form
I am not doing anything fancy. I have a very simple login script and it should just redirect to index.html afterward.
Any suggestions? To summarize, the entire site is using HTML (for now) and needs to be password protected.
<authentication mode="Forms">
<forms name="appNameAuth" path="/" loginUrl="~/login.aspx" defaultUrl="index.html" protection="All" timeout="525600">
<credentials passwordFormat="Clear">
<user name="[user]" password="[password]" />
</credentials>
</forms>
</authentication>
<authorization>
<deny users="?" />
</authorization>
In IIS7 if you want to protect *.html or *.htm files (or other non .net extensions) under forms authentication then add the following lines to your web.config:
<compilation>
<buildProviders>
<add extension=".html" type="System.Web.Compilation.PageBuildProvider" />
<add extension=".htm" type="System.Web.Compilation.PageBuildProvider" />
</buildProviders>
</compilation>
AND
<system.webServer>
<handlers>
<add name="HTML" path="*.html" verb="GET, HEAD, POST, DEBUG" type="System.Web.UI.PageHandlerFactory" resourceType="Unspecified" requireAccess="Script" />
<add name="HTM" path="*.htm" verb="GET, HEAD, POST, DEBUG" type="System.Web.UI.PageHandlerFactory" resourceType="Unspecified" requireAccess="Script" />
</handlers>
</system.webServer>
To make the HTML files locked down by your forms authetication, you need have them served by ASP.NET. You can do this in IIS by associating the extension(s) you need (eg. .html, .htm, etc) with the aspnet_isapi.dll.
Onces ASP.NET is servicing those files you can specify the permissions for them just like any aspx page.
For more information refer to MSDN:
By default, IIS processes static
content itself - like HTML pages and
CSS and image files - and only hands
off requests to the ASP.NET runtime
when a page with an extension of
.aspx, .asmx, or .ashx is requested.
IIS 7, however, allows for integrated
IIS and ASP.NET pipelines. With a few
configuration settings you can setup
IIS 7 to invoke the
FormsAuthenticationModule for all
requests. Furthermore, with IIS 7 you
can define URL authorization rules for
files of any type. For more
information, see Changes Between IIS6
and IIS7 Security, Your Web Platform
Security, and Understanding IIS7 URL
Authorization.
Long story short, in versions prior to
IIS 7, you can only use forms
authentication to protect resources
handled by the ASP.NET runtime.
Likewise, URL authorization rules are
only applied to resources handled by
the ASP.NET runtime. But with IIS 7 it
is possible to integrate the
FormsAuthenticationModule and
UrlAuthorizationModule into IIS's HTTP
pipeline, thereby extending this
functionality to all requests.
Although this is an old question, I find the link in pomarc's answer really useful. Below is the summary which is suit for IIS7.
In your web.config, add or modify <handlers> under <system.webServer>:
<handlers>
<add name="HTML" path="*.html" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" />
</handlers>
Replace verb value with your required one; scriptProcessor value with correct path of your environment.
Then, add or modify <compilation> and <httpHandlers> under <system.web>:
<compilation debug="false" strict="false" explicit="true">
<buildProviders>
<!--Add below so .html file will be handled by ASP.NET (for use of Forms Authentication)-->
<add extension=".html" type="System.Web.Compilation.PageBuildProvider" />
</buildProviders>
</compilation>
<httpHandlers>
<!--Add below so .html file will be handled by ASP.NET (for use of Forms Authentication)-->
<add verb="GET, HEAD, POST, DEBUG" path="*.html" type="System.Web.UI.PageHandlerFactory" />
</httpHandlers>
Replace verb value with your required one.
You may also include more extension separated by comma ','
I've solved the same problem a few days ago, by following the post by fr33m3 # 11-21-2007, 3:19 PM on this thread:
http://forums.asp.net/t/1184547.aspx
follow all the steps from 2. to 5. and you're done!
hope this can help you like it helped me.

how to include my asp.net website under sharepoint?

I i have the asp.net web site with c# + sql server 2008 connectivity + css + javascripts + ajax . I have a solution. i want to run this site under sharepoint . What i have to do for integrate this ?
You need to create an sub-directory that acts as a buffer to block/remove the inherited items from the .net 2 / 3.5 framework and then create your application under this.
Assuming you name the buffer application apps, and your custom .NET 4.0 application is called myapp, your resulting application would reside at:
http://[sharepoint-site]/apps/myapp/
How to do this:
Create a sub-directory apps under the root of your SharePoint
site
Go into security for the apps directory and add everyone with Read permissions
In IIS, convert this to an application and pick the same app-pool
that your SharePoint site is running under
Create a web.config under /apps/, this will block/remove the
SharePoint stuff (see below for the code block)
Create your myapp directory under apps (ex. /apps/myapp/)
In IIS, go into Application Pools, create a new AppPool, MyApp .NET v4.0
Go into Advanced Settings > Identity and add the same AD domain user account
credentials that your SharePoint site is using
Still in IIS, go back to myapp and convert to an application and pick the MyApp .NET v4.0 AppPool
Copy your code over and you're done!
The web.config file in the apps directory:
<?xml version="1.0"?>
<configuration>
<system.web>
<httpHandlers>
<remove path="Reserved.ReportViewerWebControl.axd" verb="*" />
</httpHandlers>
<httpModules>
<clear/>
</httpModules>
<webParts>
<transformers>
<clear />
</transformers>
</webParts>
</system.web>
<system.webServer>
<handlers>
<remove name="OwssvrHandler" />
<remove name="ScriptHandlerFactory" />
<remove name="svc-Integrated" />
<remove name="ScriptHandlerFactoryAppServices" />
<remove name="ScriptResource" />
<remove name="JSONHandlerFactory" />
<remove name="ReportViewerWebPart" />
<remove name="ReportViewerWebControl" />
</handlers>
<modules>
<!-- depending on any customizations, you may have to add/remove items from this list as needed -->
<remove name="SPRequestModule" />
<remove name="ScriptModule" />
<remove name="SharePoint14Module" />
<remove name="StateServiceModule" />
<remove name="PublishingHttpModule" />
<remove name="RSRedirectModule" />
</modules>
<httpErrors errorMode="Detailed"></httpErrors>
</system.webServer>
</configuration>
There are several options. The first is a simple IFrame webpart that hosts the entire application in a frame. The page viewer webpart is built into sharepoint, and does this for you.
The second is using Application Pages. I have not done this, but here is an MSDN article on them:
http://msdn.microsoft.com/en-us/library/bb418732.aspx
The third is to embed the controls of you app into Webparts, and then place these into web part zones on sharepoint pages.
The approach you take depends on the size of your app and the time you have to integrate it. The IFrame Approach is quick and dirty, while the webpart approach is much more native, but can take a long time for large apps.
I haven't had any luck trying to get another site to co-exist with SharePoint. Is it not possible for you to create this site of yours in its own web site, with its own app pool, and then just link to it from SharePoint?

Resources