When reading through the Selenium FAQ, I noticed a piece of coolness that I didn't know existed in HTTP Authentication (Selenium FAQ – authentication). RFC 1738 specifies the following scheme for specifying authentication information in a url //<user>:<password>@<host>:<port>/<url-path>. I have been familiar with this for commanline based protocols (ftp/telnet and their secure equivalents) but didn't realise that it would work in a browser. In a browser you can specify http://user:password@server:80/path to do basic http authentication. While this ia a bad idea for usernames and passwords in real applications, it is a great tool for development purposes. My firefox speeddial plugin now has development pages specified in this way.
Of course this approach is not a silver bullet, and other tools are needed. I have used this technique to access websphere portal and webapps hosted on a WebSphere Portal server, as well as applications using HTTP Authentication on Tomcat Servers. Unforutnately it doesn't work with the WebSphere administration console, but thankfully you can simulate the form based login using the following type of url: https://serverName:10039/ibm/console/secure/securelogon.do? action=secure&j_username=username&j_password=password
The combination of //<user>:<password>@<host>:<port>/<url-path> tye urls, and faking login forms, makes it possible to access most web urls very quickly in a browser environment. 1
1 -Internet explorer doesn't support this for recent browsers (see: http://support.microsoft.com/kb/834489) ↩
Related posts:










this is often useful in scripts and for mobile applications that deal with http requests and otherwise can’t authenticate using more convential popup method
Whereas RFC 1738 actually forbids HTTP authentication in URL (3.3: “No user name or password is allowed.”), it’s a very useful tool even for real applications. With Firefox-like target browsers, it can replace form authentication completely.
my goal is to develop a new layer of php authentication. (all of you are confusing for authorization) I do not understand these standards that were developed be children. it makes MUCH more sense to handle authentication through this means, rather than cookies. and you all think authentication means authorization. to sum it up; authorization is when you meet someone new and they are able to prove they are of your organization. authentication is the ability of our minds to remember that person’s face and never need to ask them again.
instead of cookies, let’s explore new ways to authenticate people in the form of:
sesion_id:unique_user_finger_print@localhost:80/index.php
skds1433 – see http://httpd.apache.org/docs/1.3/howto/auth.html
[...] note that, with this solution, the password is readable in the url and some browsers (IE only =6, this was disabled in the newer versions) don’t support this – maybe thats a problem for you. for more information, take a look at this article [...]