I am on Umbraco version 7.5.1, asp.net 4.6.1.
I have one Umbraco application hosting two web sites (one anonymous and the other secure using Forms).
I have specified this in the UmbracoSettings.Config but its good for the entire site
<error404>//PageNotFound[1]</error404>
Is there a way to instruct Umbraco to use the 404 anonymous Doc type for anonymous site and use the secure 404 document type for the secure site?
If the two websites are on different language then you can use this approach here https://our.umbraco.org/documentation/reference/config/umbracosettings/#errors
If you don´t have different languages on the site, then you could perhaps look at this package https://our.umbraco.org/projects/backoffice-extensions/umbraco-page-not-found-manager/ where you can set the 404 page from the context menu.
note: the umbraco-page-not-found-manager application only works for users that are member of userType Alias of admin. So you may have to download the code, revise it to your custom security needs.
Related
We have this web.api-project currently residing in api.mydomain.com. It is as a backend for a mobile app and also a superadminlike javascript application. We also have this new public facing website (using Umbraco CMS, in the same VS-solution) wich currently holds just your plain information (with pages like "about us", "get the app" etc) on www.mydomain.com
We've setup a asp.net membership across theese domains and are now looking to find a way to have the public site host pages like login, edit profile, start subscription etc. The controller(s) for theese views exist in the web api-project. Views would presumably exist in the MVC-project.
I am not sure what approach to take. I would preferably be able to use the viewmodels that already exists in the solution and leverage the whole Modelstate/validation-thing, returning View() from the WebApi-project etc.
We could make our edit profile-forms just to POST to the api-project (CORS is a no-go), but then the api project would have to use the hackish Request.CreateResponse in order to redirect the user to some hardcoded place back on the public site, right?
Thanks.
When I've used web-api to talk back and forth to a front-end umbraco site I've tried to make it as dumb as possible and that seems to work well. It feels wrong to couple up you web-api project to do more than send data when requested, using web-api controllers to affect the UI/Views of a website sounds wrong.
Have you considered using Umbraco Members & then configuring them to use asp.net membership (http://our.umbraco.org/wiki/how-tos/membership-providers/how-to-integrate-aspnet-membership-control-with-umbraco) - in that way the Umbraco front-end can deliver tailored stuff to asp.net membership authenticated users without all the to-ing & fro-ing from your web-api?
I have asp.net hosted at my domain which i access using a url like 'http://www.xyz.com. I have other web applications which are under the root web application in virtual directories which can be accessed using a url like 'http://www.xyz.com/subsite1 etc.
Now i want to have a sharepoint site as a subsite under my root website which i can access using a url like 'http://www.xyz.com/sharepointsite1.
I have installed sharepoint 2010 server.This installed a new website Sharepoint-80 and The central administration site. I have changed the Sharepoint-80 website setting to point to wwwwroot where my asp.net wesite and its subsite files are located. Now if i make a new site collection in my sharepoint site and it gets successfuly created. But when i browse it i get following error.
HTTP Error 500.19 - Internal Server Error The requested page cannot be accessed because the related configuration data for the page is invalid.
My webserver is also a domain controller. How do i resolve this issue? And how do i achieve the main aim of having a sharepoint site as a subsite under my main website?
Thanx
I don't think that is possible, unless you are using different host headers or you can write an HttpModule which would be complex in my opinion. Although reverse is possible, You can have a sharepoint site at / and then an ASP.NET site at /subsite
The reason is an IIS SharePoint website is different from IIS ASP.NET website. IIS SharePoint Website registers an extra SPRequest module which fetches the data from SharePoint content database. When you request / , it will always try to pull this data from the SharePoint Content database.
In your case, where you have changed the SharePoint-80 website to point to wwwroot, you have essentially removed SPRequest module from the pipeline. That's the reason you get the error, because its not able to pull the content from the database.
You should do the other way around. Change main site to Sharepoint site, and let your other asp.net application/site to be subsite of sharepoint.
You cannot do that. Simply because you're trying to encapsulate a cloud-based system into an internal IIS folder structure.
You can not add Sharepoint online page in an iframe because of the same origin policy that most of the sites on internet adopted this days. This is mainly for security reasons to avoid from web attacks like Clickjacking and XSS.
You can not add Sharepoint online page in an iframe because of the same origin policy that most of the sites on internet adopted this days. This is mainly for security reasons to avoid from web attacks like Clickjacking and XSS.
If you want to display the content of the sharepoint online into different domain, than try to use provider hosted app in windows azure or develop a Napa sharepoint hosted app which can make cross domain requests in REST or ajax
I work on an Ektron CMS solution where our site implements a membership-based access model. There are certain resources that we publish that require a purchased membership to access, others you just need to register on the site, and some are free.
We use Ektron's Aliasing extensively, which is essentially URL rewriting. So, we have resources like /about/ that map to /default.aspx?id=1234, which is available to the public, but we also have resources like /surveys/ that map to /default.aspx?id=3456 that are restricted.
How would I implement the granular access to these resources using Forms Authentication depending on the resource that is requested?
Thanks in advance.
You can wrap that url mapper, with a 'pre-mapper' that will forward unauthenticated users to different urls in case the target url is restricted.
I am sure this is a basic answer, but my search powers are not helping me today. I have an ASP.NET MVC 2 (.NET 3.5) application. It is hosted on IIS 6.
For the sake of this question I have two urls.
http://example.com/
http://example.com/admin
I want admin to be available to any user on the domain, and the root to be available to all users. The server is on the domain but the domain is example1.com, so they are not the same.
Since this is ASP.NET MVC there is no Admin folder to set rights on. I have tried setting the whole site to block anonymous request and have had it allowing all request. Then in the web.config I set it up to deny unauthenticated users in the admin folder and/or allow anonymous access to the root.
What I end up getting is a login prompt that doesn't work. I've tried the user name and example1\username but it always fails to login.
What am I missing?
==== Clarification/Answer ====
Pandincus gave a great code suggestion, adding [Authorize] to the class is a very clean way to make this work. However my problem ended up being the fact that I was doing all of this on the same box. I had a HOSTS entry for example.com on my box and was hitting it via the URL. When I put a HOSTS entry on my other box and hit the site it allowed me to log in without issue. My question was slightly incomplete as I should have mentioned this and the fact that http://localhost/ was working just fine.
Don't use the web.config to set access. Thats how you would do it in asp.net web forms.
Configure your web.config to use windows authentication.
Use an [Authorize] attribute on any admin controller you have.
Any controllers without an [Authorize] attribute should be open to the public automatically. So, only put your attribute on the controllers you want to lock down.
i have a web site that uses forms authentication. the problem is that i have the site installed multiple times on the same production servers because i need to have a few different login pages (based on the domain in this case). after the domain specific login page, the rest of the site is the same. obviously, this requires a lot of maintenance as each new version has to be installed multiple times on the server (with varying the login page in the web.config file).
so i thought is there a way to install the site on 1 folder on the disk, have a web site on the IIS take in all the needed domains and make some http module (or some other solution) in which i could give it a list of domains and the forms authentication for that domain. this way make the login page used by each site change according to the domain while still having only one site to maintain on the server.
Thanks
Dani Avni
I have seen this go a number of ways and a lot of it depends on how you have things setup in IIS.
If all domains are on the same IIS website the most common solution would be to create a httpmodule, or even an actual .aspx page, that loads configuration and based on the requested URL send the user to the right login page. You could even do a "Server.Transfer()" if you want the users URL to stay the same. Then in the web.config you still set a single login page. Just make sure that each other login page allows anonymous users access.
If all domains are separate IIS sites, i would recommend at that point just maintaining different copies of the sites. But the real question is why you need different logins.
My workplace has a couple of web applications that do exactly what you are trying to describe. There are a couple of approaches we have used, depending on the situation.
The more common approach we use is to have all the actual sites on IIS point to the same directory. The logic for the login gets the URL, determines which client site is being requested, and takes that into account on login. The actual login page is the same for all client sites, though, so it's just determining which database to use.
If you want to do anything fancier than that, another approach we have used is to create our own MembershipProvider, at which point you can basically do whatever you want. You should have access to HttpContext.Current if your class is being called by the ASP.NET authentication provider (you would set the membership provider in Web.config to your provider).