I have a web app that uses MvcSiteMapProvider, but I don't want it to server /sitemap.xml as every page but the login page requires authentication, so there is no need for the public to see my sitemap.
Is there a way to turn off the the /sitemap.xml file in config? Or a way to do it with RoutesConfig?
As per the documentation, if using internal DI, you can disable the /sitemap.xml endpoint using the MvcSiteMapProvider_EnableSitemapsXml setting.
<appSettings>
<add key="MvcSiteMapProvider_EnableSitemapsXml" value="false"/>
</appSettings>
If using external DI, you need to remove this line from the /App_Start/MvcSiteMapProviderConfig.cs file (or anywhere else it may exist in your application startup code).
// Register the Sitemaps routes for search engines
//XmlSiteMapController.RegisterRoutes(RouteTable.Routes);
FYI - although this setting does what you asked, there really was no problem to begin with. Search engines do not scan web sites for XML sitemap files, they have to be explicitly submitted. According to the sitemap protocol, they can be submitted via HTTP request, via search engine control panel, or by adding the location to the \robots.txt file. But none of these are done without explicit intervention on the part of the webmaster. In all cases, the webmaster chooses the URL that the XML sitemap will be hosted at. Unlike the \robots.txt file, there is no default location for it. We chose the most reasonable logical path \sitemap.xml, but technically it could be anything.
Related
We are building a revamped version of our old site in DotNetNuke. There are many pages that link to pages on our old site and we would like those old URLs to still lead to relevant information on the new site. The old URLs end in a variety of extensions, and sometimes in no extension (our old site is a mishmash of several platforms as well as static files). Does a DNN plugin exist that allows for such redirects? Friendly URLs aren't entirely adequate.
note: I realize that this could be handled in IIS, but we would like our non-coder, non-admin site manager to be able to handle this dynamically.
You will probably want to use a Module like this
http://www.dnnsoftware.com/forge/open-url-rewriter-for-dnn-dotnetnuke/view/extensiondetail/project/openurlrewriter
There is another option though. You can actually put URL records into the database directly, I believe you would simply add a record to the TabUrls table, the TABID is the page in DNN you want to point to. Then you put in the URL, and the HTTPStatus of 301.
You could do that for all the old pages if you know where they need to be mapped to in DNN.
You have to force all request through the ASP.NET pipeline, and you can do that by adding only this single line to the web.config of your application:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
When I browse to my startpage, e.g. /sv I get a blank page that just says "Default Page". However when I try /sv/ it works. Subpages like /sv/example work without slash though. I'm using Sitecore 7.1 with only MVC views.
Remove the default.aspx file from the web root.
That will fix your problem.
When requesting URLs without a slash at the end, the "StripLanguage" processor of the preprocessRequest pipeline rewrites path to the value of the Settings.DefaultPageName setting ("default.aspx" by default). Since such page physically exists on your site, ASP.NET MVC routing system does not handle such request, and the file itself is served. This behavior is controlled over the RouteCollection.RouteExistingFiles property (false by default), please refer to the following article for the details:
http://msdn.microsoft.com/en-us/library/system.web.routing.routecollection.routeexistingfiles.aspx.
In other case, when a slash is added after a language, this won't happen, since the "StripLanguage" processor does not rewrite the path (which is also not an expected behavior). As a result, request URL does not match the "default.aspx" static file in the site and request is getting processed by ASP.NET MVC.
I suggest you to add the following setting to the "Web.config" file (instead of creating a "default.aspx" page), which points to the "default" page without extension:
<settings>
<setting name="DefaultAspxPageName" value="default"/>
</settings>
After that, the /default URL, without ".aspx" extension, will be processed by MVC and the appropriate item will be rendered independently of a slash after the language URL section.
On my side it works.
I want to point out that the answer to this is not my own but given from the support over at Sitecore who I want to extend a big "Thank you!" to. I had googled this forever until they helped me and I thought that I want to have this document and easily found when others struggle with it. A bug is filed and they are working on fixing it.
DefaultAspxPageName is Hidden Setting.. We can find more such hidden settings..#
http://www.newguid.net/sitecore/2014/sitecore-hidden-string-configuration-settings/
I have 2 applications under the same website in IIS7.5. The problem is the follow:
Open the browser and login the first application;
Open another browser tab and login the second appication;
The first application automatically logout.
I have the same asp.net authentication DB but I created two different users with different roles and different ApplicationId. I also set different applicationName attribute in membership provider configuration in applications web.config file.
Can you help me please? Sorry for my English.
Thanks.
If the IIS website is configured to use Forms-Based Authentication, then the problem is most likely that the cookie for the 2nd login (which is a different user) is overwriting the cookie from the initial login. By default, the cookie is named ".ASPXAUTH". You should be able to verify this by inspecting the response headers returned from IIS using something like Fiddler.
You can control the cookie name IIS uses to maintain the session by changing the "name" attribute in the element in the web.config. See this documentation for more details. An example of this portion of the web.config would be something like:
<authentication mode="Forms">
<forms loginUrl="login.aspx" name="APP1SESS" />
</authentication>
If the applications are contained within single, separate sub-folders, then you could also use the "path" attribute instead to tell the browser to only send the cookie for requests in that sub-folder. Be careful here as any shared resources like images that are not in the sub-folder would need to be publicly accessible.
The //authentication/forms element can only be specified at the root level of the application. Check this SO post for a discussion on that.
I've a MVC 3 web application using WIF (only thing that matters here is that it's a http module and integrated into the processing pipeline), I've added in normal error handling via global.asax.cs's application_error handler. This works well for most of the cases where the basic application is up and running.
however, there is a class of errors where if the web.config is not configured correctly. (i.e. after a fresh install), the http modules, i.e. WIF assemblies throw exceptions.
I'm trying to put a custom error page for that as well to ask the user to look at the configuration,
however, any page hosted on the same website, even for static html still goes to the standard asp.net error page. My guess is that its still invoking the modules for static pages. Any one have idea on how to disable the httpmodules for certain areas or what the standard practice is?
This is how i'm configuring the custom error page
<customErrors mode="RemoteOnly" defaultRedirect="~/error.htm">
it's a simple static html page. page loads fine when the website is configured properly, but does not show when there is a http module level problem.
You can specify default websites setting in machine.config file. And even protect them from overwrites.
The machine.config file is located in x:\\Microsoft.NET\Framework\\config\machine.config
So if after deployment web.config file will be broken (or some settings) - proper settings will be taken from machine.config.
So I am having this issue of getting CSS files applied through the masterpage. I had another question: Can't get CSS loaded in Master page that helped me to apply the link tag correctly (or different options).
This is confirmed in Firebug where the call is coming back 302 found, but the styles are not being applied.
This question lead to another contributor pointing out possible access issues to the controller/content in my Web.config. Thus the reason for this question separate "Security" related question.
I have went through a number of full MVC app tutorials such as NerdDinner (v.1, v.2) and Pro MVC 2's not to mentioned a good bit of reading material in my pursuit to learn ASP.NET MVC - and I have not come across any details on access to sources such as /Content to anonymous users just to load css files. Nor have I read anything that MVC takes the approach that it is entirely locked down and you must open specific areas to specific roles/users/everyone OR open it all up for everyone.
So I still have the problem of not being able to get CSS rules applied even though it shows that the .css file is being found (302). But another issue is that I am seeing a second call to load the file in the console:
localurl.com/Account/Logon?ReturnURL=%2Content%2AdminViews.css
But errors with a 500.
Now I have commented out the logon URL line in my web.config "Authentication" section, and there is no route that I can see in my route dictionary.
Any thoughts on both of these related issues?
UPDATE
I found that the problem with why the redirection to the
localurl.com/login.aspx?returnurl=content/adminview.css
was that theforms authentication (in IIS) was enabled with the properties set to "Login.aspx". Changing this generated an ACL rights (yellow screen of death) when accessing the file directly
localurl.com/contents/adminview.css
I found adding users to the content directory (i.e. IUSR account) would rectify this issue.
So I now need to find what the proper way to set security. What account I should use ...etc. I did already have the IUSR_ComputerName already given access, which my understanding is the default IIS anonymous user account. So why this wouldn't be enough to access resources in the ~/contents/ directory is beyond me.
You could allow access to these resources using web.config.
<location path="Content">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>