I wonder if the following is possible.
A user logs in on my website, using a username and password using his default browser.
Later on, my C# program is run on the same PC. I want to check if the user is logged in in the default browser, so I can access a webpage that is in the registered-only area. Is this somehow possible?
I number of possibilities come to mind:
You could check their cookie folder for a valid cookie for your site
Check the browser history (perhaps using a toolbar)
Use the web browser control so that users log-in through your app
I have never seen either of the above in practice.
I think the best method would be to set up the site to ask for credentials if they're not logged in - so the user can enter them and continue. You'll find this method in most (if not all) of the major websites out there that have client installed software (such as the Gmail Notifier)
You could possibly do it with a cookie saved on the machine, you would need to find where its stored and the naming of the cookie or some kind of api to read the cookie.
here is a few links
http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.cookiecontainer.aspx
http://msdn.microsoft.com/en-us/library/system.windows.application.getcookie.aspx
http://bytes.com/topic/c-sharp/answers/677862-reading-creating-cookies-local-machine-using-windows-application
http://www.codeproject.com/Messages/2981086/How-to-read-cookies-in-winforms-Net.aspx
Related
I have a ASP.NET/C# website using IIS that when a user logs in successfully (Using login control and checking oracle table for user info) I create a session variable that lets the site know the user is authenticated. I have also created a Wiki site using Media Wiki which I have hosted on a different web server. I'm going to link to the Wiki from my main website where the user logged in.
What I need to do is when a specific users log into my main site I want them to be logged into my Wiki site as well when they navigate to that page. I want them to be able to edit the Wiki without having to log in again.
This will only be for a handful of people that will be flagged in my user table on my main site and already have user accounts on my Wiki site. What would be the best approach?
I did read the information on the Media Wiki website and it wasn't helpful for IIS and how to set it up. For MediaWiki to know what user I want to have be logged in to I have to manually set the remote_user enviroment variable or can I tell MediaWiki to look for my session variable value?
The internal MediaWiki mechanism for this is the SessionProvider (somewhat complex and the documentation is highly technical). A simple implementation that just pushes the burden of authentication to the web server software is the Auth remoteuser extension.
Otherwise, if you share a domain, you could set cookies in your primary application in some kind of verifiable fashion (e.g. digitally signed) and verify them on your wiki. If you don't, the wiki will have to trigger a web request to the primary application, which would check the cookie and respond with an authentication status, and the wiki would set its cookies based on that.
I have a login screen, and upon successful login i will display a welcome screen. But the problem is if i refresh the web page. i am taken back to the login screen. If i am successfully logged in, then if i refresh i should go to the Welcome page.
I did some research and found out that i should be using cookies to handle this. Is cookies the best approach or are there any other way i could solve this ?
Could someone please point me to a good tutorial that explains how to do this? or some sample code to start with?
Here is the MSDN on the FormsAuthenticationTicket class that is used for authorizing users to your application. This is the term that you want to ask about/Google for more information on user authentication.
The basic premise is that once you have authenticated a user, you issue an encrypted cookie that contains some basic information about that user. This cookie is what is used to prove the user is who they say they are, defines the login expiration times and allows you to authorize them to different resources in your application.
Words of Caution
With that said, if you are rolling your own authorization/login system, I highly encourage you to use the built in .NET membership providers. There are many caveats to web authorization and authentication and the likelyhood that you leave a security hole open using your own code is extremely high.
Here are some other approaches that don't require cookies:
if you can use authentication provided natively by browser (i.e. Windows if your case is intranet with Windows domain) than you can base your decision on headers other than cookie header (i.e. in case of Windows auth you can use "impersonate request as user" functionality) to see if user is "logged in" to your system.
you can also set information on local system in Local storage to say "this user is logged in" and than check on login page if some other page needs to be rendered. This is not secure approach, but it maybe ok (as you still need to have some way to secure all other pages).
I have a few websites which allow both anonymous and window auth users at the same time. Basically if you hit the site with IE or Webkit based browsers on a windows system, the server instantly recognizes your active directory user and group.
In the past I've provided a link to a windows auth only page which allows the current user to login, or bounce back to where they started.
I find the management of this kind of frustrating as I need to make certain that IIS has the correct security settings for that single page after every deployment.
Is there a better way for me to allow a user to elevate from anon to authenticated?
There is no other way to do that elevation automatically. The server can't know that the current user is a Windows user and elevate them, or automatically redirect them to the Windows auth only page. On the other hand, if every user will get through the Windows auth only page, all of them which are not inside the domain will see the challenge/response dialog box (user + password).
As for the management part of making sure that this special page has the correct security settings, you can (and should) automate the check somehow. For example, by querying the IIS metabase for that setting when the application starts (in Global.asax) and if the setting is not there, log it as an email message or so.
Personally I prefer a different attitude - a special "integration/deployment" page which contains a series of tests against my application so I can make sure everything's set up correctly on the server, i.e. NTFS write permissions to certain folders, availability of the SMTP server set in web.config to send emails through, etc.
Note: You're using Windows authentication along with anonymous access. Just keep in mind that if you consider implementing Forms Authentication in the future, a misarchitecture (I don't know if by design or due to a flaw) of IIS 7 does not allow you to set the app to be Forms Authentication and set one specific page to be Windows Authentication. The override just doesn't work and it's very frustrating.
Good luck!
OK, I figured out a fairly nice way to do this...however it's not as elegant as I had hoped since it doesn't work across applications.
Basically, if you create a single page within your Anon + Integrated Auth IIS6 website or virtual directory, let's call it auth.aspx, then you can use this page to prompt authentication.
Go into IIS settings and specify that auth.aspx is Integrated Auth ONLY (no anon). Then create a hidden iframe somewhere on your page. I then created a simple JavaScript action to update the src attribute of the iframe to the auth.aspx page. This forces the browser to try and authenticate using NTLM. Once you enter valid credentials you've successfully elevated your current user beyond the generic anonymous user.
One final touch was to then include a Response.Redirect into the auth.aspx which reloads the current page. Assuming your ASP.net session tokens are set correctly, the page will reload and the user will be authenticated.
Currently I am using windows authentication but several of the non technical users seem to have trouble entering their credentials when the browser requests them. The web app needs to be able to identify the users to keep track of their input throughout the site. I was initially thinking cookie but I would need to be able to tell which users entered what and the possibility of them clearing their cookies could cause issues. windows Authentication would be great if I could just get around requiring the users to enter their credentials.
On a properly configured network, internet explorer users should not have to enter their credintials. Furthermore, I think all the other browsers have settings to do automatic NTLM authentication (Chrome and Firefox definitely do).
What do you mean "have troup entering their credientials"? How do they log in to their computer?
Right now, I have all the employees of my company login to an external website using the company id, username and a password. We are trying to integrate it into an intranet portal which should provide seamless access to this website without requiring the user to enter these credentials.
Is there any way of doing this programmatically (.NET C#)? Very similar to screenscraping, Can I simulate the appropriate POST action and then redirect the user to the logged in page?
Any help is appreciated.
Thanks.
You can make a <form> in your page that mirrors the external site's login form with the same action= attribute, then fill put and submit it using Javascript.
Note that this requires that you send the user's password to the browser, which is never a good idea.
You can certainly post to the external website, the tricky bit will come when you redirect the user there, because there'll be cookies restrictions I think.
You might be able to do something with Javascript that makes the Client browser post directly to the third party with the correct credentials, look into jQuery's Post command.
Assuming that the external website maintains sessions with cookies in some way, the problem is, your company website can't set a cookie, except from it's own domain, and the 3rd party website can't read cookies except from it's own domain, so you can't transfer or pass the cookie across to your users.
The name for this technique is Single Sign-On. There's no one way to do it, but the emerging standard is called SAML. This requires participation on both parts (the originator and target website), so it's probably beyond your current purview.
Like the other two answers have mentioned here, you can post a formatted request directly to the action of the login script, but I can tell you from experience that that solution will be brittle, that is, it will shatter the second the target website makes any changes.
Your best bet is to contact the administrator of the target website and ask if they have an SSO (Single Sign On) solution.