Does a Silverlight video player share the HTTP connection with its host?
Here is the scenario: a web site is password protected. The web page contains a Silverlight control with a video player. The video player plays a video from the same web site. Will the credentials from the web browser be used by the video player? I use MediaElement.Source to specify where the video is coming from.
If not, how can I fix this?
That depends on the way it communicates with the server... for example the webrequest class can be set to use BrowserHTTP or ClientHTTP...
BrowserHTTP uses the browser's HTTP implementation including Referer, Cookies etc.
ClientHTTP allows you to manage HTTP setting like Cookies manually...
Using MediaElement.SetSource you can leverage whatever connection you please (BrowserHTTP / ClientHTPP) with you specific settings (including Authorization header / Cookies etc.) as log as that connection provides a Stream interface for the content...
Further details see
http://msdn.microsoft.com/en-us/library/system.net.browser.webrequestcreator.browserhttp%28v=vs.95%29.aspx
http://msdn.microsoft.com/en-us/library/system.net.browser.webrequestcreator.clienthttp%28v=vs.95%29.aspx
http://msdn.microsoft.com/en-us/library/cc838250%28v=vs.95%29.aspx
http://msdn.microsoft.com/en-us/library/cc190669%28v=vs.95%29.aspx
Related
If browsers use http to connect to server ,and in any web application when we hit the URL and the request is received by a controller mapped to the URL ,can we say browsers are also rest client
That would depend entirely on what you use as a browser but generally no, a browser lacks meaningful tooling to probe a RESTful server out of the box, and comes with features that otherwise would not be needed by a REST client application, so would not be considered a REST client. A browser might be considered as a more generic HTTP client, but even that does not fully describe the problem domain of a browser (rendering, scripting, etc.). Even if you build a web interface to probe a REST service by submitting forms, that does not make the browser a REST client, but instead your website/web application would be the REST client application.
Yes,
the protocol the browser uses to communicate with the webserver clearly initially is a restful protocol.
Nothing more is necessary.
But it can get a bit more complicated.
The browser can fetch application code (javascript) in a restful way (e.g. GET) and execute that code which further can be communicating (Ajax) restful.
I've created a virtual desk page that will run in a browser (IE11 or chrome) in kiosk mode, I want to to put the result on a big touchscreen display in order to allow the users to explorer the intranet site through the kiosk.
In the page I have also an iframe which shows other sites in my domain mycompany.com.
I'm trying to build a policy for which sites shown in the iframe are allowed to follow href to other pages but disabling mailto and file link ( in order to avoid the the browser open the e-mail client or the file explorer).
Of course, I cannot change the code of the original sites shown in the iframe and I know that I cannot override the href with a JS in the container page because of the same-origin policy.
Is there a way to obtain this ?
I've found the attribute sandbox of iframe tag in HTML5 but I'm not sure about to use it in order to accomplish the task.
Any ideas ?
Use the desktop app, registry edits or zone policy to control this:
An app can register to become the default handler for a certain Uniform Resource Identifier (URI) scheme name. Both desktop apps and Windows Runtime apps can register to be a default handler for a URI scheme name. If the user chooses your app as the default handler for a URI scheme name, your app will be activated every time that type of URI is launched.
By default, Internet Explorer prevents navigation to Uniform Resource Identifiers (URIs) using the "file:" protocol when the current URL matches the following conditions:
The current URL is opened in the Internet zone or the Restricted Sites zone.
The current URL uses a protocol other than "file:".
For a mail client, the program needs to have registered settings under the HKEY_CLASSES_ROOT\mailto key in order to service URLs that use the mailto protocol. Set values and keys that mirror those settings under the following key.
HKEY_LOCAL_MACHINE
Software
Clients
Mail
CanonicalName
Protocols
mailto
The RegisterProtocolHandler API will work for Chrome:
Chrome 13 finally includes navigator.registerProtocolHandler. This API allows web apps to register themselves as possible handlers for particular protocols. For example, users could select your application to handle “mailto” links.
Register a protocol scheme like:
navigator.registerProtocolHandler(
'mailto', 'about:blank', 'Mail Protocol');
The first parameter is the protocol. The second is the URL pattern of the application that should handle this scheme. The pattern should include a ‘%s’ as a placeholder for data and it must must be on the same origin as the app attempting to register the protocol. Once the user approves access, you can use this link through your app, other sites, etc.
References
Registering Programs with Client Types
Internet Feature Controls (D..H)
Understanding Protocols
How to Handle URI Activation (HTML)
Registering a custom protocol handler | Web Updates - Google Developer
I have a web page of asp.net using c#.I am now want to implement the hardware security that any hardware identification should be fullfiled before opening the web page.I meant if allow the that hardware of client then it will open the web page otherwise it should make error of authorization etc.Is there anywat to do this that i can detect client hardware identificaions and then allow to open the web page.Plz help !
No, there is no way to detect the client hardware directly through the browser.
The User-Agent http request header can give some information about the user OS, but still remember that users can modify and send whatever headers they please. Not something you should count on for security.
The web does not allow you to lock users to hardware, and it is IMO a bad practice.
You can at the server keep track of active sessions, and allow only a certain number of sessions per user.
I have a Flex frontend connecting via RemoteObject to Zend Framework's Zend Amf. This is my only means to transport data between client layer (Flex) and the application and persistence layers (LAMP with Zend Framework).
Some ways I can address security are as follows:
I can address TLS by using mx.messaging.channels.SecureAMFChannel in my services-config.xml file and ensuring Flash player is loaded into a HTTPS wrapper and is in fact using HTTPS since the AMF protocol is layered on top of HTTP
RemoteObject has a setCredentials method with which I can pass AMF authentication headers to protect user related data. Assuming TLS was actually secure I can expose methods on the endpoint after authenticating the User.
I can protect against cross-site scripting and other FLASH vulnerabilities with a properly set up crossdomain.xml
The question I have is how to I protect my endpoint against another AMF consumer? For instance, if there were another AMF consumer (not Flash so not bound by crossdomain.xml and Flash sandbox security) other than my Flex client that knew my endpoint, what would stop it from using methods that the endpoint exposes?
As far as I know I essentially need a way to authenticate my Flex application against my Zend Amf endpoint. After AMF consumer authentication, I have some of the security mechanisms I mentioned above to protect certain pieces of data (like User authentication). I can not embed some sort of authentication mechanism into my Flex swf because the swf is vulnerable to decompilation (the swf can not be trusted). While sensitive data is protected via User authentication the unprotected data is hardly public but as far as I can tell is totally open for public consumption.
You cannot prevent anyone from sending arbitrary HTTP requests to your endpoint. If your Flex application authenticates users against the server, and the server only serves sensitive data if the request has proper credentials / session IDs on it, everything is fine. What you can not do is authenticate the user and only store within the client that the user is authenticated. Since HTTP is a stateless protocol, the server must be able to authorize each request individually. It's the same thing with "regular" websites and AJAX.
AMF client can not know who called them unless some sort of authentication is provided. Any HTTP request that Flex sends could be emulated by non-Flex means, and as you correctly noted, any embedded key could be extracted. So there's no generic solution for this, though you could probably work something out if you gave your client certificates for HTTPS connection and made the server check the client certificates.
I was thinking about integrating some instant messaging function into an existing ASP.NET web application, e.g:
the web application can display the online-status of users (are they currently logged in with their IM client)
users can send messages from the web application to the IM client of other users
users can initiate a IM chat from the web application (without having to know the other user's IM identification beforehand)
Does anyone know about some existing libraries, sample applications or other resources that might help implementing such a feature?
Thanks a lot for sharing your knowledge.
You should try Jabber. Demo client avaiable here.
There is an architectural overview, the main concept looks like this:
(source: webta.net)
And some citation from the site:
1. Goal
Create an multi-service instant messaging AJAX-based web application with internal accounting.
2. Main problem
We need to connect to IM servers from HTTP client (browser).
HTTP is a stateless protocol. This means that, theoretically, each HTTP request is being proccessed by separate http daemon proccess.
Once request proccessed (data sent to client), server fogets about client.
All IM services protocols are stateful.
When client connects to IM server, socket connection being created and connection much remain open for succesfull communication.
There's a list on the ASP.net site.
http://www.asp.net/Community/Control-gallery/browse.aspx?category=54
You might want to look at the .net implementation of jabber:
http://code.google.com/p/jabber-net/