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?
Related
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.
I built an ASP.Net MVC 4 application which uses forms authentication by means of a custom membership provider inheriting from the Simple Membership.
Everything is working fine, but now I have a new requirement: I need to integrate a JSP application with mine.
This means that it has to authenticate against the same user database of my application and that they should somehow share the session in order to achieve a kind of Single Sign-On among the two applications (if an user is already authenticated in the ASP.Net application, he should be able to access the JSP application without logging in again, and vice-versa).
What architecture do you suggest me to use?
I would like to change as little as possible the ASP.Net application.
Thanks!
If you need to auhtenticate accross different domains:
You can implement your own security token service (like facebook, google does) Here is some ready to use implementation: http://thinktecture.github.io/Thinktecture.IdentityServer.v2/
If the sites are running on the same domain (subdomain), then you can try to share an authentication cookie within these domains.
An explaining article: http://www.codeproject.com/Articles/106439/Single-Sign-On-SSO-for-cross-domain-ASP-NET-applic
Currently using DNN 5.2.x and we are using only 1 portal on the site. We need to make a mobile version of the portal and eliminate most of the extra DNN stuff as info will be just displayed. So what we decided to do was create seperate ASP.NET Web Forms website and utilize the DNN providers (membership, roles, etc) to do the logging in. However we are currently having issues. The one in particular is ("unknown exception trying to write to log"). We've moved most of the DNN Global.asax (i.e. SimpleContainer instructions) file to the new website and added the necessary web.config sections and references however we get this error when a user logs in. We did copy over the same web.config machine key to the new website. The connection strings are also there (app settings and connection string sections and is named SiteSqlServer).
So my question is, has anyone created a new website around DNN without using DNN except for the membership? i.e. no modules, no skins, etc. Just validate user and get roles.
If you have what needs to be done to get DNN 5.2.x (or later) to log a user in and return the roles, could you post your steps?
The default DNN login is based on ASP.NET membership. If all you really want is the login feature, it will be MUCH MUCH easier to simply use the ASP.NET membership directly than try to rip it out of DNN.
What you are trying is not impossible, but certainly will require substantial patience with trial and error.
For only validation users and getting roles you could write your own simple providers that utilize dnn special tables in the databse like (Users, Roles, UserRoles, Profile etc). The table User is associated with the aspnet_Membership and aspnet_Users standard tables via the Username field.
There are many options which are open for you.
If you really don't want to digg into complecations of how to integrate the dnn membership and role provider will work, you can check dnn single sign on
Another option is to have your webforms application as a subfolder in your dnn website. that way you don't have to do much effort and you will have all the good things ready to get started. even you can directly convert your skin to master page and reuse almost all the css and image related suff
In addition to above, I also suggest another smart way to do this. Since you are considering a mobile site, why don't you try and detect the browser using Request.Browser and create a separate skin for dnn that is of smaller size. We can easily switch skins dynamically for service requests.
I hope this will help. If you have more questions regarding this, I will be happy to help. Just drop me and email and I will try to help you get as close as possible to get you going.
Good Luck
This is the route we took. We basically implemented DNN in the mobile version of the website. Except we only utilized the User Membership features of DNN. To do this we had to use all the same core DNN dll's and also include all the "bootup" features in the global.asax file. We also had to on every request inject a UserInfo object into the session context. I forget the key name for the UserInfo oject used but it is used by DNN and must be set in a DNN handler that we did not incorporate. Other than that it works perfectly. We have the ability to get all the roles a user is in and etc.
I have been Googling a problem that I have with trying to integrate the web application that I am working on with SharePoint 2010.
The web application is a wiki style tool that allows users to log in via forms authentication or WIA against Active Directory and create content for themselves and others.
What we would like to do is to allow a user have a page with the content they have created in our web application mixed in with content that they have living on the SharePoint server. For example, they may want to see a list of documents that they have on the SharePoint server mixed in with some of their content.
To accomplish this, we would like to take the credentials the user has logged into our web application with (for example MYDOMAIN\jsmith) and be able to query SharePoint for the documents of that same user (MYDOMAIN\jsmith) WITHOUT the user being prompted to re-enter their credentials to access the SharePoint server (we are trying to avoid the double-hop problem)
We have come up with some options for how we want to do this, but we are unsure of what the best approach is.
For example, we could
- Have a global user, shared by all users to get information we need from SharePoint. The downside is that we cannot filter SharePoint content to a particular user
- We could store the users credentials when they log in, but that would only work for users authenticating via forms auth and would be a security issue that some users/clients would not like
- Writing a SharePoint extension using WCF to allow us to access the information we need, however we'd still have the issue of figuring out how to impersonate the user we want.
Neither of these options are ideal and in our investigation we came across the Claims Authentication/STS option which seems like it is trying to solve the problem we are having.
So my question is, based on what I have written, is Claims/STS the best approach for us? We have not been able to find much direction on how to use this method to call into SharePoint from a Web Application and pass along the existing credentials.
Does anyone have any experience with any of these issues?
It sounds like you may be overcomplicating the problem. The reason that the user gets asked for credentials twice is that the two parts of the system are on different servers. The easiest solution is probably to implement your custom web app as custom pages/web parts within SharePoint.
If that isn't an option, a smaller amount of code on the SharePoint server (maybe a custom web service) should give you a few more options for impersonating a particular user.
I am creating a standalone asp.net page that needs to be embedded into a sharepoint site using the Page Viewer Web Part. The asp.net page is published to the same server on a different port, giving me the URL to embed.
The requirement is that after a user is authenticated using Sharepoint authentication, they navigate to a page containing the asp.net web part for more options.
What I need to do from this asp.net page is query Sharepoint for the currently authenticated username, then display this on the page from the asp.net code.
This all works fine when I debug the application from VS, but when published and displayed though Sharepoint, I always get NULL as the user.
Any suggestions on the best way to get this to work would be much appreciated.
If you want to retrieve the currently authenticated user from the SharePoint context, you need to remain within the SharePoint context. This means hosting your custom web application within SharePoint (see http://msdn.microsoft.com/en-us/library/cc297200.aspx). Then from your custom application reference Microsoft.SharePoint and use the SPContext object to retrieve the user name. For example:
SPContext.Current.Web.CurrentUser.LoginName
You can still use the Page Viewer Web Part to reference the URL of the site, now located within the SharePoint context.
Thanks heaps for the answers!
Turns out that as long as the asp.net page is using the same URL and port as the Sharepoint site, authentication works across both sites.
The solution is to use a Virtual Directory inside of the sharepoint site and install the asp.net page there.
When it works in debug, is that being used in SharePoint?
Your page and the Sharepoint site might as well be on different servers as far as authentication is concerned -- in order to get the information over you might need to pass it via the QueryString from the webpart if you can -- or you might need to make your own webpart to do this (just put an IFRAME in the part with the src set to your page with the QueryString passing the username).
It does seem that this would be a security issue if you use the name for anything though -- if you are just displaying it, then it's probably fine.
If you actually need to be authenticated, you might need to add authentication into the web.config of the site hosting your standalone page.
edit: I think you'd have better luck putting your page on the same port and server as SharePoint.
I suspect you will have a hard time specifically querying SharePoint for the currently authenticated username. I can't think of a way to easily access the SharePoint context from a separate web application like you are describing.
I don't know what kind of authentication scheme you are using, but you may want to consider using Kerberos, as I've found that it can make these kinds of scenarios a little easier by allowing for delegation and passing credentials from application to application or server to server.