BACKGROUND: We are giving our web site users the ability to create fundraising pages.
TECHNOLOGIES: asp.net 3.5 (web forms), Sitecore CMS 6.4, IIS 7
ISSUE: I'm trying to determine which url scheme is most convenient for users and which is more maintainable from a code perspective.
Idea #1: Create a subdomain - fundraising.mysite.com/johnspage
Idea #2: Use main domain - www.mysite.com/johnspage
Here are some thoughts that come to mind about using sub domains or not.
THOUGHTS:
We are using Sitecore CMS 6.4 so we will not be creating a separate website if we use a sub domain. The sub domain will simply point to the main domain.
If we use a sub-domain or not I plan on having a handler that redirects each fundraising page request to an actual page which looks up the users fund raising information and displays it. (the handler will inject a cookie or querystring). If we use sub domains it will be easier for our handler to know the request is for a fundraising page.
If we use a sub domain I want our handler to redirect to our actual site. This will avoid cookie issues between domains and sub domains. (Sure the cookie issues can be overcome, but I want to avoid them out of the box). So if the request is fundraising.mysite.com/johnspage the handler would turn this into www.mysite.com/actualpage?parameters... (or maybe use cookies)
With a subdomain we can avoid the issue where a user creates a page that has the same name as an existing 'real' page. We are using Sitecore CMS so pages don't actually exist in Sitecore but we would not want a users fund raising page to resolve to a sitecore item. (if you are not familiar w/ sitecore you can think of trying to avoid the problem where the users fund raising page has the same name as one of your existing pages, using a subdomain makes this problem easier to manage. I guess you could also do this w/o a sub domain just put the handler logic early in the http request pipeline).
When the user goes to share their page, www.mysite.com/johnspage might be easier to remember for the user. They could simply say go to mysite.com/johnspage instead of fundraising.mysite.com/johnspage. The subdomain makes the url different then the main site and longer to pronounce. Sure users can cut and paste any url we give them, but if they are verbally sharing the url then having a sub domain could be inconvenient.
QUESTION: Would you use sub-domains or point to the main domain or is their another approach I am not thinking of? Any other thoughts you can provide?
Maybe I am misreading your question, but these statements are telling me that you don't want an actual item for each fundraising 'page.'
redirects each fundraising page request to an actual page which looks up the users fund raising information and displays it
as well as:
we would not want a users fund raising page to resolve to a sitecore item
I might suggest that you look into using 'wildcards' and setup a structure such as:
/sitecore/content/home/fundraisers/*
Now, your sublayout/rendering for the wildcard page would be responsible for resolving the specific user, fetching the data and render it.
There are a bunch of resources on Sitecore Wildcards such as:
http://www.sitecore.net/Community/Technical-Blogs/Getting-to-Know-Sitecore/Posts/2011/09/Wildcards-and-Data-Driven-URLs.aspx
Related
I have a client that has a SilverLight app that contains all of their products. They are wanting to create HTML pages (now that they realized they aren't getting indexed in Google) for all of their products. On those pages they want a link to the silverlight app that will open a specific product.
I'm not a WPF developer, so I'm not sure what is possible. My first thought was maybe we can pass an id to the SilverLight app and then put some code in place to switch to the correct product.
Any ideas?
Thanks,
Cole
In the asp.net host application, you can read the parameters from the query string and pass them to the silverlight plugin in the InitParams section.
More info can be found here.
Ideally you want to detect that it is Google (or another search engine) hitting your site and direct the user/search to an appropriate page (Silverlight page for people and HTML pages for Search Engines).
Navigation in Silverlight uses bookmark URLs on a single page (like website.com/silverlightpage/#item=1234) whereas your site will likely use MVC mappings (like website.com/item/1234).
From a user-experience perspective you just want to click a result in Google and go straight to the Silverlight bookmark URL equivalent.
To do this you need to catch incoming URL requests in your web site, identify any search engines, and if it is a real person redirect them to the Silverlight app page (e.g. with item id passed into the bookmark).
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).
I have a question that doesn't need any specific answer, just a general direction of what to do. I work for a company that has many sites. Each site requires a login at some point. We have a single Accounts database that all of the sites hit.
One of the requirements for the login system is that if we login on one site, we should automatically be logged in elsewhere.
The way it works right now is that on page load (or init, forget which) at any of our sites (let's say site1.com), it redirects to a "master" site (let's say sitemaster.com). On sitemaster.com there is a web service which checks to see if a cookie exists on sitemaster.com for that user. If it does, it redirects back and lets site1.com know that the user has already logged in (site1.com then creates a cookie for site1.com so we don't have to redirect to sitemaster.com in the future). If the user is not logged in at sitemaster.com, site1.com will then ask the user to login and, on submit, it redirects the user to sitemaster.com which logs them in, creates a cookie under sitemaster.com domain, redirects back to site1.com and lets site1.com know that the user is logged in (which then creates the cookie for site1.com).
On logout a similar method is employed.
Is this the best way of handling universal logins, or auto-logins across multiple sites? Is there a better way of doing things?
Some requirements:
Most of our sites are in .NET 2.0, but there are plans to update them all to .NET 4.0. We want the best method for this auto-login system so if something requires .NET 4.0, that's ok.
The solution should not require javascript (our current solution requires javascript during the login process).
The solution should not require Flash.
It's ok to use iframes, as long as javascript is not requred.
We would like to be able to do AJAX logins (using jQuery) without having the site refresh. The current solution, due to the redirects, prevents us from doing that. (eg: Pop up a modal box asking the user to login, and when they do, the modal box disappears and some content is changed, but no site refresh required). This isn't absolutely necessary, but at the very least we should be able to verify a login using AJAX before any redirecting takes place.
Any articles or suggestions will be very helpful. I also have some questions related to the best way of re-using the auto-login code across sites (varying from ASP.NET 2.0 Forms to ASP.NET 4.0 MVC, but I'll save that for another question).
Bara
At a simple level, your system works very much like OpenID. It might be worth implementing your own internal OpenID provider and save yourself all of the custom work and maintenance/bugfixes etc for a bespoke system. OpenID is supported by many many sites, including stackoverflow.com.
http://openid.net/
and
http://wiki.openid.net/Run-your-own-identity-server
which leads to:
http://www.dotnetopenauth.net/
-Oisin
What you've described is a federated Web Single Sign-On scheme. Ultimately, I'd recommend that rather than rolling your own, you adopted the WS-Federation standard. The advantages being that you're less susceptible to introducing security vulnerabilities and also have the ability to achieve Single Sign-On with applications other than bespoke ASP.NET apps.
Our customer has a requirement to extend the functionality of their existing large government project. It is an ASP.NET 3.5 (recently upgraded from 2.0) project.
The existing solution is quite a behemoth that is almost unmaintainable so they have decided that they want to provide the new functionality by hosting it on another website that is shown within the existing website.
As to how this is best to be done I'm not quite sure right now and if there is any security issues preventing it or that need to be considered.
Essentially the user would log on to the existing web site as normal and when cliicking on a certain link the page would load as normal with some kind of frame or control that has within it the contents of the page from the other site. IE. They do not want to simply redirect to the other site they want to show it embedded within the current one such that the existing menus etc are still available.
I believe if information needed to be passed to the embedded page it would be done using query strings as I'm not sure if there is even another way to accomplish this.
Can anyone give me some pointers on where to start at looking to implement this or any potential pitfalls I should be aware of.
Thanks
if the 2 sites are hosted from the same network (low latency between them) you could use state server for session management. that way, when you authenticate on one site, you will also be authenticated on the other, and share user state across them.
its pretty simple, in your web config of each web server you'd point to the state server (which could be located on one of the web servers)
<configuration>
<system.web>
<sessionState mode="StateServer"
stateConnectionString="192.168.1.103:42424"
/>
</system.web>
</configuration>
http://en.csharp-online.net/ASP.NET_State_Management%E2%80%94Storing_Session_State_out_of_Process
create a virtual directory under the primary domain. If your domain is www.mydomain.com then create a virtual directory www.mydomain.com/site and port the new website application under /site virtual directory. This was linking should become very much relavant. With this the virtual-directory application will also retain all domain cookies set by primary domain.
I would suggest to make the second website look exactly like the first one or at least use the same MasterPage, so you can redirect from one site to another without any visual difference.
If your site needs authentication, consider that you would need to do something to prevent the user to log in twice, an option could be to send an encrypted token to the second site.
All of this if you are forced to have a second site, if not just use a virtual directory
You could use something like UFrame. I've used it a couple of times and seems to do quite a good job with it...
"goodness of UpdatePanel and IFRAME combined"
http://www.codeproject.com/KB/aspnet/uframe.aspx
I would use an iFrame to embed that website in within your existing application. Just set the "src" attribute and pass in any query string parameters the other site needs to render correctly.
You can still pass in sensitive data in the query string, however it would make sure to encrypt it before sending it in.
I know it is not the most elegant solution, but it gets the job done. And from the description of the existing app, it doesn't seem like your customer cares for "elegance" :)
Hope this helps
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.