I am trying to open a url which needs username/psw combination from a desktop app. Desktop app already has an authentication mechanism. What i want is if someone tries to open the url then i'll pass the access token from desktop app to the web, so that user don't need to login again.
One crude way to do this is to check the default browser using registry and depending on the default browser set the cookie in their local sqllite file(for chrome and firefox). But this approach doesn't seems to be the good one.
Is there any other way to do this ?
The most crude way would be to pass it as a query string parameter. This may not be ideal as you might not want it to show, although you could have the target site do a quick redirect after authenticating. You also want to be sure to only do this over HTTPS.
Another way if you'd prefer to POST the data would be to write out a local HTML file with a form that auto submits on load. Have the access token in a hidden field on the form. This would allow you to do a POST.
In either case, you can launch a browser to a specific page using Process.Start("https://example.com/mypage").
Related
The problem I'm having is with IE and other browsers by default looking for client certificates in the Certificates - Current User. I want to grab a specific one from the Certificates (Local Computer) store (I've got the code written for this already) and use it as the one the user chooses or choose one for them if possible. Choosing one for them would be the optimal solution.
Also I'm not 100% locked into using WebBrowser, but I just need a way to embed a browser into a windows form and have that web browser be able authenticate via client certificates. I have code written that does this via HttpWebResponse, but I wasn't able to use it inside my WebBrowser.
I am currently working on a project for which there exists both a mobile app and a web site. One task can be performed on either the web site (meant for desktop users) or the app. Right now, the requested functionality for the site is as follows:
If a desktop user visits the web page, continue on that page as usual.
If a mobile user visits the web page, redirect them to the installed mobile app.
I have already implemented logic to tell whether the user is on a desktop or mobile device (most of the time, at least); however, it occurred to me that some users may not have the app installed, or that a desktop device could be incorrectly identified as a mobile device in the future. If a computer that does not have the app installed is redirected, they will encounter some error or an about:blank page. So, my question is, is there any way to tell whether a Response.Redirect to a mobile app will succeed?
So far I have investigated the HttpWebRequest/HttpWebResponse option to try and determine success or failure based on a requested page response prior to the redirect, but this does not seem like a valid option since a URL linked to an app will not provide a valid URI for the HttpWebRequest to test with. Any assistance or advice would be greatly appreciated. Thank you!
For clarification, the redirect looks something like this:
Response.Redirect("opencustomapp://SomePage?Parameter1=bar&Parameter2=foo");
The expected result is not to open a web page, but rather to interact with an app installed on the user's phone which has been mapped to this url.
EDIT: I have accepted the answer that it does not seem possible to do what I was asking for, but in case others have this problem, I wanted to attach some useful links to other questions about how to use a cookie to determine if the app is installed and how to redirect the user to some other place if the cookie is not set. For my own code, I will probably be going with a combination of a user-agent check and the setTimeout() function, as this can be implemented from code-behind using ClientScript.RegisterStartupScript without requiring any changes to the existing app.
No, there is no way to tell at the server if the redirect would succeed. This is because the redirect is sent back to the client from your server and executed at the client. Probably the best thing that you can do is use the mobile app to set a cookie for the website on the device, and then check for that cookie on the server side of the request... if it exists, redirect. Be careful to clear the cookie if they delete the app (if possible, not super familiar with mobile apps), otherwise the redirect would fail.
I am currently developing an app that uses a public API. After performing the login procedure with that API, I get a cookie that I store in my app. I need to pass this cookie with every API call, that I request. So far so good.
Now unfortunately this API doesn't give me acces to all features of the service. What I want to do is giving the users of my app a button, which open a WebBrowser for that specific features. The problem is, that the user is, of course, not logged in in that WebBrowser.
What I found out on my PC is, that the login-cookie, that I get from the API, would actually work for the website itself as well. So what I want to do is: When the user clicks on the button, it opens the WebBrowser and passes the login cookie I already have to the WebBrowser, so the user is already logged in and can use the feature. Is there any solution for that problem? I couldn't an answer for that.
Cheers! :)
You can only set cookies from invoking javascript on the page when loading is completed.
Windows Phone WebBrowser set cookies
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.
Platform: ASP.NET 4.0, VS 2010
My scenario is this
I have the credentials of an external website
I do a couple of GET/POST to scrape some data off of it
Depending on something that I find, I want to give my user a hyperlink that, when clicked, takes him 3 levels deep into the target website beyond the login page
Of course, I could just provide a URL to the top level on the target site, and he would click through to get there. But is there a way, via ASP.NET, that I can programmatically login and then open the page on a separate window/tab?
I think that, to have the user avoid the login, you're going to have to scrape that page and present it to the user yourself. If you pass the user along to the page at all then he's going to have to authenticate against it. Your application on your server authenticated, but the user in his browser did not. Unless there's some strange (and terribly insecure) quirk about the destination page, it's not going to trust that the user is you.