I have a ASP.NET MVC Web Site running with Siteminder SOO.
Al security is working correctly, except the Home Page.
In the SiteMinder configuration i have only one Realm with Resource Filter: "/" and Default Resource Protection: "Protected". So, all uris are protected. And i have rules for each uri, and a set of Domain Policies that works fine with these rules. The problem is the root page; i don't know how to write a Rule that allow access to the home page, for example: "http://misite.com/".
If I create a Rule with resource = "/", then the Effective Resource is: "my-siteminder-agent//". And a policy with this rule never applies.
¿How can i create a Rule to allow access to the home page for authenticated users?
I solved it using a Rule on SiteMinder to allow Access to '/Home' and a redirect with the IIS Rewrite Module.
<rewrite>
<rules>
<rule name="Root Hit Redirect" stopProcessing="true">
<match url="^$" />
<action type="Redirect" url="/Home" />
</rule>
</rules>
</rewrite>
You could also create a unprotected rule to allow the specific home page... ie index.htm
Change the rule to * instead of /*
If the entire site needs to be secured you do not need to create multiple rules for different paths. A standard rule covering everything will be sufficient. Refer to the Answer by #bcarroll to set that up. It will make your life easier when you have to make changes to the policies etc. later.
Related
Have a .net webapp running on IIS.
I have run across something I haven't had to really deal with before. we have partners or clients that have their own "pages" on our domain. currently the URL is www.mydomain.com/?code=partnercode, but for ease of use on business cards and such they want it to be more like www.mydomain.com/partnername and I am not sure how to do this.
I know we can do something like the following in the htaccess in Apache
RewriteRule ^partnername$ index.php?code=partnerid [L]
I am wondering if there is some way to do this in the web.config? there has got to be something, but I am unsure where to look to find it. I have tried those online htaccess to web.config code converters and it failed miserably. The other thing is I would prefer to not have to change the partnerID that we already have in the DB.
I found this on another question on this site but I don't think it will do what I need it to. It will change the URL in the browser one the user hits the page but I also want it to be accessible using the www.mydomain.com/partnername URL as well.
if ( $_SERVER['REQUEST_URI'] == '/index.php?code=partnerid') {
echo '<script type="text/javascript">window.history.pushState("", "", "/partnername");</script>';
}
IIS has extension that partially supports your scenario, it is called URL Rewrite.
I said partially, because you can use it to rewrite URLs from www.mydomain.com/partnername to www.mydomain.com/?code=partnername. What it doesn't support (at least I don't think it does) is mapping a partner name to partner code (unless you have small number of partners and you can add rewrite rule for every partner).
And here is an article showing a fraction of what you can do with URL Rewrite.
In your case if you want to rewrite www.mydomain.com/partnername to www.mydomain.com/?code=partnername, your rule configuration could look something like this (not tested on IIS):
<rewrite>
<rules>
<rule name="Rewrite to query string">
<!-- I'm using hardcoded text, but it is regular expression and you can
write very advanced conditions -->
<match url="^(partner)" />
<!-- changes incoming url /partner to ?code=partner -->
<action type="Rewrite" url="?code={R:1}" />
</rule>
</rules>
</rewrite>
I wrote a redirect rule that will route client's content requests, to the linked Azure CDN serving my hosted ASP.Net MVC website on an Standard plan.
I tried several iteration of the rule; nothing is working
These are the steps I took to implementation
Create Storage
Create CDN ENDPOINT http:// azxxxxxx.vo.msecnd.net/
Created a subdomain at GoDaddy verified and pointing to azxxxxxx.vo.msecnd.net/
Created a public container using Cloudberry Explorer
Uploaded images blobs to the container and
Tested content availability successfully on the browser at http:// azxxxxxx.vo.msecnd.net/images/test.jpeg
Tested content availability successfully on the browser at https:// storage.blob.core.windows.net/images/test.jpeg
inserted the Rewrite-redirect rule on the site web.config file
<rewrite>
<rules>
<rule name="CDN Redirection" stopProcessing="true">
<match url="^images/(.*)" />
<action type="Redirect" url="http:// azxxxxxx.vo.msecnd.net/images/{R:1}" />
</rule>
</rules>
</rewrite>
......( No using the custom subdomain name yet waiting for propagation)
Save, stop and restart website, clear cache, F12, inspect element .....nothing, content still being pulled straight up from the website
So what am I doing wrong?
Check my website at http://www.ehubcap.net
Thank you
This is a simple rule that is tested and works on Azure Websites:
<rule name="images redirection" stopProcessing="false">
<match url="images/(.*)" ignoreCase="true" />
<action type="Redirect" url="https://double.blob.core.windows.net/images/{R:1}" redirectType="Permanent" appendQueryString="true" logRewrittenUrl="true" />
</rule>
Note, you don't need the ^ in your match pattern.
You can check the result here - check the original page source first - IMG element refers to a local image: http://double.azurewebsites.net/images/some.jpg, which is being redirected by the URL Rewrite to the blob storage (you can redirect to any domain you wish).
Note, however, that URL Rewrite module is dependent on other modules. For best results, the UrlRewrite Module should be the first module to process the result. If you have enabled static and/or dynamic compression to compress the output, the URL rewrite will not work. This is because the default configuration kicks the compression module first, then brings the URL Rewrite module. And the URL Rewrite module cannot read compressed content. Yeah, don't ask me why. So, first disable compression (if you have enabled it) to check the URL rewrite config. Then try to reorder the modules. The simplest would be to first remove them, next add the URL Rewrite and then Compression module.
I want to direct some of my other domains to my primary domain which is hosted at a Windows Azure website.
(For the sake of those that find working with CNAME's and DNS a little "foggy" (like I did) I'm going to layout the details.)
I have the domain www.myDomain.example correctly resolving.
I now want to point www.myOtherDomain.example to www.myDomain.example
At my registrar I have created a CNAME to point
www.myOtherDomain.example to myInternalAzureSite.azurewebsite.net
and then successfully configured it in the in the Azure Website domain manager tool.
Now, when I enter www.myOtherDomain.example into a browser I get the proper web page at www.myDomain.example, however, the address in the browser is still www.myOtherDomain.example not www.myDomain.example as desired.
I understand the two most desirable ways to accomplish this are either:
Forward myOtherDomain.example (which costs $ at some registrars)
Do a 301 permanent redirect
If I have all that correct, I have found many suggestions of HOW to do the 301 redirect, however, I can't seem to figure out WHERE to actually put the redirect?
Windows Azure Websites run IIS. You can use URL rewriting to create rules to rewrite one URL to another.
Instructions:
Create a website in Windows Azure.
In the Scale section, select a web site mode of Shared or Standard and save changes.
In the Configure section, on the domain names group, add the old domain name (or names) and the new domain name and save changes.
In your domain registrar or DNS provider for the old domain and the new domain, change the DNS records to point to the new Windows Azure Website. Use a "CNAME (Alias)" record and point it to the website's domain on Windows Azure, like this: "mywebsite.azurewebsites.net."
Upload your new website's contents to Windows Azure.
In the root of the new website, create a file named Web.config with a contents like this:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Redirect old-domain to new-domain" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern="^www.old-domain.example$" />
</conditions>
<action type="Redirect" url="http://www.new-domain.example/{R:0}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Verify that any request to http://www.old-domain.example/path?query will receive a "301 Moved Permanently" response with a Location header for http://www.new-domain.example/path?query.
For documentation refer to Using the URL Rewrite Module.
For examples refer to Redirect to new domain after rebranding with IIS URL Rewrite Module and IIS URL Rewrite – Redirect multiple domain names to one.
There's no need to upload web.config file as there is one that you can access through the Azure interface.
Open the settings pane for your App Service and click App Service Editor (Preview) in the Development Tools section towards the bottom of the left hand menu.
Click Go to open the Editor in a new tab. You will see the web.config file on the left. Click it to edit in the main pane.
One word of warning - this editor autosaves as you type! I'm sure we'd all do this anyway but I'd recommend preparing your code in an editor and pasting it in.
I was able to add a section without having to manually restart the App Service.
You can also do the redirect by placing this code in your web.config file under the configuration node:
<configuration>
<location path="oldpage1.php">
<system.webServer>
<httpRedirect enabled="true" destination="http://example.com/newpage1" httpResponseStatus="Permanent" />
</system.webServer>
</location>
<location path="oldpage2.php">
<system.webServer>
<httpRedirect enabled="true" destination="http://example.com/newpage2" httpResponseStatus="Permanent" />
</system.webServer>
</location>
</configuration>
I've taken a simpler approach and just added the extra required domains to the Azure App Service via the Custom Domains menu - per the screenshot below. No need to touch the main websites web.config file at all. No need for any explicit 301 redirect. In Custom Domains page, just assign the domains, add the SSL bindings by uploading your HTTPS certificates - hit the site!
We have a new Sitefinity site that is replacing our marketing site. The switchover happened last friday, and we uncovered a problem today: there is content (pdfs, jpgs) on the old site that can no longer be accessed, and did not make it into the content migration plan. On top of that, management has removed rollback as an option.
So, the solution I have come up with is to use IIS 7's url rewriting module to point to a new url that hosts the old site so that content can be accessed. This is the xml in my web.config that I have come up with:
<rewrite>
<rules>
<rule name="RedirectFileNotFound" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
<add input="{URL}" negate="false" pattern="/\.*$" />
</conditions>
<action type="Redirect" url="http://www.oldsite.com{REQUEST_URI}" appendQueryString="true" />
</rule>
</rules>
</rewrite>
It attempts to test if the URL resolves to a file or folder, and makes sure that we are requesting something with an extension. If the rules pass, it redirects to the same location on the old site. Ideally, this would mean that anything linking to the old site previously would be able to be left alone.
The problem is, nothing gets redirected.
By fiddling with the rules, I have verified that the module is operational, i.e. i can set it up to rewrite everything, and it works. but these rules do not work.
My theory is that since Sitefinity uses database storage, it somehow short circuits the "IsFile" match type. Complete guess, but I'm kind of at a loss at this point.
How to I use urlrewriting to redirect for 404's in this manner?
I am not sure how the rewriter is implemented, but those rules seem to be too general. Sitefinity uses the routing engine and registers a series of routes that it handles. By definition, those routes are interpreted sequentially, so if a more general rule exists before a more specific one, the latter will not work.
I suspect what may be happening is that the Sitefinity rules already handle the request before the rewriter gets a chance to redirect it. What I can advise is to either implement more specific rewrite/redirect rules, or just handle the whole issue using a different approach. What was the reason your old files were inaccessible after the migration? Can you give a specific URL that fails to return the file, so we can work with a scenario?
this is just a shot in the dark, but do you have "file system fallback" enabled in the sitefinity advanced settings for libraries? perhaps the module is intercepting the request and not letting it proceeed to the file-system...
Thank you guys for your help, but it turned out to be a problem with Dynamic Served Content in general.
Assume that all requests are actually handled by a Default.aspx page. This isn't the way that Sitefinity works, but it is the way that DotNetNuke works, and illustrates the problem nicely.
The url rewrite isfile and isdirectory flags check for physical existence of files. In this case, only Default.aspx actually physically exists. All the other dynamically served content is generated later in the request cycle, and has no physical existence whatsoever.
Because of that, the isfile flag will always fail, and the redirect rule will always execute.
The solution I went with was to allow IIS and .NET to handle the 404s themselves, which properly respects generated content. and route that to a custom error page, 404redirection.aspx. There is code on that page that redirects to my old site, where that content is likely to be host. That site then has additional 404 handling that routes back to the 404NotFound.aspx page, so requests for files that don't exist in either system make a round trip and look like they never went anywhere. This also has the nice side effect of pages that aren't found on the old server get to display our new, pretty, rebranded 404 on the new server.
Simply put, rather than attempting to pre-empt the content generation and error handing, I took a more "go with the flow" approach, and then diverted the flow at a more opportune time.
I've got an Search Engine Optimisation problem where users are able to access my site by specifying any sub-domain. This is causing duplicate page issues with SEO.
For example if a user mis-types 'www' then posts a link on a forum, google is crawling 'wwww.domain.com'. Furthermore, google is also crawling 'domain.com'.
I need a way of forcing the site to always redirect to 'www.domain.com' regardless of how the user accesses the site.
Is it possible to do this in the web.config file? If not, how else can I achieve this?
Cheers, Curt.
You can do this using the IIS URL Rewrite module. Here's the config to rewrite domain.com to www.domain.com:
<system.webServer>
<rewrite>
<rules>
<rule name="Canonical host name">
<match url="^(.*)" />
<conditions>
<add input="{HTTP_HOST}" pattern="^www\.domain\.com$" negate="true" />
</conditions>
<action type="Redirect" url="http://www.domain.com/{R:1}" />
</rule>
</rules>
</rewrite>
</system.webServer>
You might need to modify the regex a bit or add a second rule to support rewrite of specific subdomains as well.
Unfortunately URL Rewrite module is not available on IIS6.
If you want to use url rewriting, you could check one of the following:
http://www.isapirewrite.com/ (not free)
http://urlrewriter.net/ (free)
http://cheeso.members.winisp.net/IIRF.aspx (my favourite)
Ah, just did this!
Set the default site to just redirect all calls using URL Redirect to your www.site.com, then create another site with your actual content that binds just to the www subdomain.
This will mean that all traffic will be redirected to the www site if there is no other binding available.
This has worked perfectly for me:
IIS 6 how to redirect from http://example.com/* to http://www.example.com/*
I had to change a bit of the code to get it to work with my Url-Rewriting, but apart from that, spot on!