Our application uses the Chromium Embedded Framework. We need a way to communicate to our servers within our requests that they are communicating with a Chrome browser embedded in our application. Changing the user agent isn't really an option because some sites do not play well with browsers which are not recognized. I suppose we could get around this by appending the application name to the end of the default Chromium user agent header. Our server could then check to see if the user agent header contains the name of our application. I'm unsure though if some sites will still have an issue recognizing our application with this method. I'm also unsure if there is better way to indicate this, maybe through the use of cookie or setting a custom field on the request header?
Related
I have a single solution with multiple C# ASP.NET Web Forms projects. I want a way to identify a given browser so that each website can identifier that same browser. I need to do this from the C# Code-Behind code (not with the client code, like JavaScript). I also cannot use the Session because it isn't shared across websites. I don't think cookies are either.
For example, if a user logs onto Website1 and then logs onto Website2 with the same browser on the same computer, I want to be able to identify that. But if a user logs onto Website1 with Chrome and then Website1 with FireFox (regardless of whether it's on the same computer or not), I want to detect that as well.
If it makes any difference, I am using Azure to publish my web projects. So all websites will have similar domains (eg website1.azurewebsites.net and website2.azurewebsites.net).
If you want to track someone using the same browser on the same computer then use a cookie. If the websites have different domains you'll need to be clever because modern browsers have a lot of protection against what they see as tracking cookies. One option is using a hidden interstitial page as described here.
Your second scenario, a user accessing same site with different browsers, I suggest storing the user agent string (one of the request headers) and adding this to a login audit so you can build up a collection of different user agents used by a given user. There are libraries available for parsing user agent strings and extracting name, version, engine etc.
Between these two techniques and a bit of business logic you should get what you need. If you would like me to clarify any of this, let me know and I'll provide more detail.
My app is Windows based, and there is IE installed. But my app will run in a process which does not like externally-launched applications (like a web browser, when authorizing). Instead, my app will use the host application's web features to display a browser.
The host app takes over the front-end and is a public kiosk-type application, so I have no control over how browsing gets launched. The google drive api automatically launches the default browser (with an affinity toward Chrome, even if not the default... :-/
I cant give code examples, but you need to look into non browser based auth - i.e. server side authentication https://developers.google.com/drive/web/auth/web-server?hl=en
I have a program that opens a web browser control and just displays a web page from our server. They can't navigate around or anything.
The users are not allowed to know the credentials required to login, so after some googling on how to log into a server I found this:
http://user_name:password#URL
This is 'hard coded' into the web browsers code. -It works fine.
HOWEVER: Some smart ass managed to grab the credentials by using WireShark which tracks all the packets sent from your machine.
Is there a way I can encrypt this so the users cannot find out?
I've tried other things like using POST but with the way the page was setup, it was proving extremely difficult to get working. -(Its an SSRS Report Manager webpage)
I forgot to include a link to this question: How to encrypt/decrypt the url in C#
^I cannot use this answer as I myself am not allowed to change any of the server setup!
Sorry if this is an awful question, I've tried searching around for the past few days but can't find anything that works.
Perhaps you could work around your issue with a layer of indirection - for example, you could create a simple MVC website that doesn't require any authentication (or indeed, requires some authentication that you fully control) and it is this site that actually makes the request to the SSRS page.
That way you can have full control over how you send authentication, and you need never worry about someone ever getting access to the actual SSRS system. Now if your solution requires the webpage to be interactive then I'm not sure this will work for you, but if it's just a static report, it might be the way to go.
i.e. your flow from the app would be
User logs into your app (or use Windows credentials, etc)
User clicks to request the SSRS page
Your app makes an HTTP request to your MVC application
Your MVC application makes the "real" HTTP request to SSRS (eg via HttpClient, etc) and dumps the result back to the caller (for example,it could write the SSRS response via #HTML.Raw in an MVC View) The credentials for SSRS will therefore never be sent by your app, so you don't need to worry about that problem any more...
Just a thought.
Incidentally, you could take a look here for the various options that SSRS allows for authentication; you may find some method that suits (for e.g Custom authentication) - I know you mentioned you can't change anything on the server so I'm just including it for posterity.
I am using VSTS 2008 + C# + .Net 3.5 + Silverlight 3.0 + ASP.Net to develop a Silverlight application (a video media player) in browser and the function is simple, just use MediaElement to play a remote video file.
The remote server is Windows Server 2008 + IIS 7.0 + IIS Media Bit Rate Throttling Control.
Since the request media URL can be discovered (e.g. from traffic sniffer), and I want to know how to prevent from download directly from the Url? i.e. I want end user to use my Silverlight media player application in browser to play the file, prevent them from download to local directly. Any easy and quick solution or reference code/documents?
I might be clutching at straws here but what about using a HTTP handler to intercept requests to the media URL: When the HTTP handler encounters a request, it checks for a unique HTTP header in the request - this could be hard coded into your media player application so that the URL request is accompanied with the appropriate security header - and unless the HTTP header is present then all response is blocked. I know there are no code specifics here but it's an idea all the same.
Use the ASP.NET Authentication Service to authenticate/authorize your user
Put the video in a folder where the web.config prevents un-authenticated access to the contents
If I'm not mistaken (and to be truthful, there is a chance as I've never tried this particular scenario) ... that will protect your video content, while allowing the authorized user to access it via silverlight.
What Joel suggested above could make sense. Especially if the Silverlight hosting web application was running in an app pool that ran under a particular identity (i.e. "svcMyVideoApp"). Then you could make it where only this identity could access the content folder. Set all other requests for content to deny (except maybe your own :) )
If i'm not mistaken... if properly set up, IIS 7's media services shouldn't even serve the raw files no more then it should serve a raw unprocessed "aspx" page.
I only played with this a little a few months back, but when I installed the Media plugin for IIS 7, it was not serving the raw media files, and I could only access them via a silverlight interface. I used Expression Studio to create my silverlight viewer page and had it encode it for "smooth streaming".
A simple way would be to add a handler to catch the request like #pb said. I don't know if sending headers is the right thing or not though. A simple way would to just check if the request has a referrer..
String.IsNullOrEmpty(context.Request.ServerVariables["HTTP_REFERER"])
or you'll need authentication and to send the auth cookie with the request.
I'm using WPF and C#.
I want to be able to launch a browser window, most likely IE, and provide known credentials so that the Windows-based application can handle the transition from itself to an outside browser without having the user enter his/her credentials again.
I do know how to launch the browser:
System.Diagnostics.Process.Start(url);
My main question is, how can I attach authentication to that? Perhaps by adding headers to it somehow?
Lastly, I don't really want to use the new WebBrowser control inside of WPF due to it's current problems with displaying with a transparent window.
1) You have to know how to "log in".
To do this login manually in the web application and trace the http traffic with http debugger like Fiddler. Pay attention what kind of http requests are sent, what names have the parameters, etc.
Once you know what sequence of http requests has to be send to log in you has to do this with the browser.
2) Implement log in automatically
2.1) If by any chance log in happens via http GET - just append the right query string to the url and start the browser. This could happen only if you control the web application and build in this mechanism, other wise log in is almost always implemented as POST with https.
2.2) If you have to do POST request you have several options:
2.2.1) You could provide local html document, that contains javascript and make ajax call to the login form from the javascript. To pass the parameters you could use get parameters.
2.2.2) If nothing else works you will have to use the browser via COM (WebBrowser control)
It's going to depend on how the web site handles user authentication. If you own the website, you can create a url that will log the user in with the information you provide.
Nick,
The authentication will be handled in different ways: -
Proxy Authentication is handled by Windows manually.
Forms Based authentication is handled by cookies, so the user needs to have the cookies present.
Windows NTML might be in the 'keychain' on the Operating system (Remember this password).
Cheers,
Phil.