My company has a MOSS 2007 Enterprise (SharePoint 2007) website with users already setup. Everything is working fine. The users are setup in Active Directory. Now they want something really complex. I know how to do it in a few weeks in an ASP.NET website. That is my bread and butter. Here is what I would like to do.
I would like to write a new ASP.NET website using Window Authentication, and just have the users jump into the new application when they new this new ability. All of this has to be accessible from the internet. It is an External application. The external user accounts are in Active Directory already.
Will the identity still be the logged in user then they arrive at my new website?
NOTE: I do NOT what them to have to login again.
How can I do this?
NOTE: I am learning SharePoint Development. We have it. It is important to me to learn it. However, I am a little overwhelmed by it at the moment. We have 20+ developers, and NONE of us know anything about SharePoint. A consultant set it up, and a non developer is administrating it. In the future I will probably be the "man" in the future. That is a scary thought. SharePoint is something I want to know, however I have too much on my plate the next 2 months and NO help. I would like to get the application completed, and then move the code into SharePoint later if there is a need and a reason to do so. If there is no need, then we will keep it seperate.
It depends on several factors - specifically will the domain name change when jumping between the two applications: e.g. moss.domain.com vs. asp.domain.com...
An effective way to deal with external Single Sign On (SSO) is to stand up an ISA Server that will act as the gateway to your servers, and it will handle all the sign on details. You can even have the credentials be used across subdomains or setup custom URL routing such that all visitors hit www.domain.com and based on the url (/sites/* would go to MOSS, /app/* would go to your ASP.NET site.
Related
I am going to need to host multiple websites in IIS, but will not have separate URLs setup in DNS for each one. Because of this, I will not be able to use the Aias/CNAME functionality in IIS to redirect traffic to individual Websites in IIS.
Would it be secure enough to publish all of my web apps to the same Website in IIS?
Example: under Default Website, there is a folder for each individual web app:
-Default Website
--[folder for webapp1]
--[folder for webapp2]
--[folder for webapp3]
URLs used to access each web app:
www.mydomain.com/webapp1
www.mydomain.com/webapp2
www.mydomain.com/webapp3
Is this sort of setup secure or a good idea (best practices)? It seems like a simple solution to the problem of not having a separate domain name in DNS for every web app (website).
What do you think?
I don't see any issue with that approach, in a way it does simplify things quite a bit actually.
Sites being secure is not going to be affected by this. Of course each application would be under it's own pool, it's always a great idea to run like this.
This being said, your main website is going to run under it's own application pool and if there is a problem with it all your applications will be affected. That's the one thing I would pay extra attention to so you might want to not actually use that top level app pool for anything.
Im a little lost here. Im starting on a project for a customer who wants a SaaS solution as a small portal.
The idea is that i make a web solution e.g. an online business card, where each customer should have their own domain like this:
www.carpenter.com
www.painter.com
www.masonry.com
Etc. each of these domains should point to my web application and each have their own administration web site and the online business card. This means that if I go to: www.carpenter.com I should see the companys online business card. And at the url: www.carpenter.com/admin the carpenter company should be able to log in and edit its information.
I hope this makes sense.
What Im looking at is how this is done in practice, I would like to have a central database and a central place to update my software (maybe one per country). What do i need to do to point a www.carpenter.com domain/url to its own specific area in my web app. And how do I need to structure my web application to do this?
Im using ASP.NET MVC for this, but this should be a general question regardless of language - or?
Im considering using a cloud service such as Azure, is this possible with this setup? Or do i need a virtual hosted server i own myself?
I guess the main question is "how do I host multiple domains on the same software" - and keep the display of the "business card" and admin separated from each customer?
Not sure if this specifically answers your question, and my experience thus far has not been with ASP, but I think the general idea is that you determine the execution environment for your web app early in the bootstrap process, and then set constants and configuration options at that point. Then, you can use those values throughout your application to customise the response based on which site you're working with (i.e. carpetner, masonry, etc.). And, since the only piece of differentiating information you have during the bootstrap process is the domain name and URL of the site being requested, I think the generally accepted method is to switch on the domain name. So, you can store different configs for the different sites based on their domain names, and then load those configs during the bootstrap process. For example, if you had a different site template for your carpentry site and your masonry site, you could store the path to your templates as one of the configuration options. HTH
I need some guidance in "best practice" for the following scenario:
I have a product that consists of an ASP.NET website and native smartphone apps for Android/iOS/WP that uses the website URL to call webservices.
We want to move the website from "www.ourdomain.com" to a sub domain like "www.login.ourdomain.com"
This means we're going to update the apps to point to the new URL which isn't a problem.
But as we all know, not all users update their apps instantly, so we want to have a "cross over period" where we run the website on both URLs.
It'll use the same database, but the ASP.NET site code will be altered a bit for the new sub domain site.
Is there any problems in doing this kind of cross over where 2 ASP.NET sites share the same database? (All id's in the db is auto incremented, or GUIDs)
Any help, suggestions or concerns is much appreciated.
I don't see any problem using different service URL for existing mobile apps(Old URL) & updated mobile apps(new URL) and website. I'll call it proxies.
The critical part is regression testing for mobile apps (old one & new one), with the latest change.
It would be great, if deployment fully incorporates the Deployment Workflow.
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've developed my first web application which, surprisingly, is getting very popular.
Because the website is now live, I have a hard time doing some changes, in fear some people are still logged in and are using the application.
I wish to avoid having a duplicated instance of the web application for testing.
Is there any way to put the website in 'maintenance mode' with only me having access to it? Like redirecting to a page with some info, telling its in maintenance mode.
I wish to avoid having a duplicated
instance of the web application for
testing.
That's your problem right there. For anything but the most trivial sites, you should have a staging or development instance. You should be using source control and have a script to update the main instance.
You can simply drop a file called app_offline.htm in the root of your website and ASP.NET will automatically route all traffic to this page. This file can contain any HTML you wish indicating that your site is down for a short period due to maintenance.
For more information please read App_Offline.htm and working around the "IE Friendly Errors" feature:
The way app_offline.htm works is that
you place this file in the root of the
application. When ASP.NET sees it, it
will shut-down the app-domain for the
application (and not restart it for
requests) and instead send back the
contents of the app_offline.htm file
in response to all new dynamic
requests for the application. When
you are done updating the site, just
delete the file and it will come back
online.
This is the answer to your question:
http://www.codeproject.com/Tips/219637/Put-the-website-in-Maintanance-Mode-Under-Construc
There's no such built-in functionality in ASP.NET except app_offline.htm which doesn't quite fit your needs because even you will be denied access to the site. You have to build it on your own but this is best done on the routers and load balancers level than at the application level. Of course this will depend on your network architecture.
Besides building a dev replica of your website to build patches and fixes on, couldn't you just announce a site closing for maintenance several days in advance? I'm not a web programmer, but you might want look into what Hattrick, a popular online soccer management, does for maintaining their site. They use a notification system on the homepage, after users sign-in, that announces when maintenance will be taking place (usually late at night in Europe where a large portion of the players and all the devs are located) and they close down the website for a couple of hours. When they take the site down they post a page, using the same style as the rest of the site, and provide an estimate of when it will be up and running again. Simple, elegant, and when coupled with the long forewarning it seems to do a good job placating the user base.
Give users a long heads up that planned maintenance is scheduled to take place and give them some idea what it is for and most people will be able to accommodate the down time. Nothing is more frustrating than purposefully going to a web app that was up and running 10-20 minutes ago to find it suddenly unavailable and down for maintenance.
Try app_offline.htm ??
What version of ASP.NET? I'm sure there are a million more elegant ways of doing this, but you can change the Default Document in IIS to redirect to Maint.html (or similar).