I use Htdigest authentication with lighttpd. When the user first logs in to the website, a standard username/password dialogue box is presented. If correct username and password is entered, user can login, otherwise lighttpd shows an Authentication failure page.
So far so good!
The problem is when the user wants to logout, the browser doesn't forget the username and password. In other words as long as the browser is open, user can return to the same site without being asked to authenticate. One solution can be to close the browser so that it forgets the authentications But I don't want to force the user to close their browser everytime they want to log out.
Is there a way using JavaScript or server side code (ie. PHP, Python or Lua) to let the browser forget the htdigest authentication?
PS. We use Lua 5.1 on the server side which is not as powerful as PHP but it runs as FASTCGI in Lighttpd 1.4 on Linux 2.6.
It can be done, but is tricky. There is no default way to do this. Conclusion drawn from various sources:
You have to trick the browser in forgetting the user/password combo. This can be achieved by letting the logout page send a 401 Not Authorized response header. Unfortunately the details vary per browser.
Related
So I noticed with SharePoint sites if you are using IE, it automatically sends your AD username/pass to the server. Now I'm being asked if the same can be done with the other internal websites. The other websites are written in php and I don't have access to the server settings, just to the php scripts. I did find a way to authenticate against AD from php scripts once the username and password gets submitted to the scripts. So I'm like halfway there once the script knows what user/pass, the user wants to use it can check if it's valid. but what I still need to know is how to tell IE that this page needs to know the user/pass they are logged in as like the SharePoint site pages can.
Is it possible to use a Windows session to authenticate a user so that my Apache httpd/PHP web application won't require additional authentication? I would want to know from the Windows session who the user is so I can restrict functions on a per user basis, but I don't want the user to have to log in again.
I see some articles about using LDAP from Apache, but it's not clear to me if that just lets me verify the login information after requesting credentials or if it allows me to make the login seamless/invisible...
What you looking for is basically impossible (or almost impossible). You want your Apache to be able to access Windows session. Apache speaks through HTTP protocol only. Browser in your Windows is the one who speaks HTTP. There nothing in HTTP what can instruct your browser to ask Windows session user name. The only way around it to have JS embedded in your page. But again your browser will prohibit your page from getting this information. Why? Because it is ENORMOUS SECURITY THREAT!
There nothing in HTTP request from a browser what can tie it up with particular Windows session and hence it cannot be done.
I was wondering if there was a way to force an iOS device to login to a php page each time they send a request to the page.
Currently, after I log in the first time, I have to restart the application to force it to ask for credentials to be sent again. I have tested this behaviour with a webpage, and after the login prompt shows and I enter the password correctly, I do not have to enter it until I restart the browser and go to the page again.
I was wondering if there is any way to change this behaviour either server or client side to force the server to request credentials every time a request is sent.
If information about being logged in are stored in session (which I think it is - but it depends on application) you can f.e. reset session after each request.
In other words: run same action that will be run when user is logging out, but after every request.
As much as Esse's answer is good for server side, I found an easier workaround client-side, setting the NSURLCredential storage to NSURLCredentialPersistenceNone. This stops the phone from storing the basic auth credentials. As this site is not intended to be used by browser's this is a decent work around
I have very specific problem.
I have web based application which set cookie after login. The same login details are used in desktop application which is connected to the web interface.
My idea was is it possible that when the user logins first in web app and it set cookie for him, then he downloads the application, install it on his PC and start it for first time somehow to get the user and password and auto fill the login fields in desktop application, so it won't be necessary to write them second time.
One of the ways is to save the login and password in a plaintext in cookie, which is very risky and then the desktop app gets this cookie from the browser (the app is written in c++).
I really don't have any clear idea at the moment how this could be done, but if there is a way I will be happy to red any of your suggestions.
The main issue I see is actually getting to the cookie. I can't see how you'd do that reliably with all the OSes / OS versions, browsers / browser versions out there. You could maybe include an encrypted resource file in the download containing the credentials. You can put that into the downloaded archive on the server side.
Is downloading without a login really not an option?
Edit: including a one-use token in the download, using which the client can fetch the username and password (via SSL, encrypted, somehow safe) looks like a good bet.
I am in need of an authentication system that would work in harmony with the current authentication system my client's server uses.
The current system works as follows:
A page requiring authentication invokes an in-house developed mod_auth Apache module in the .htaccess file.
The user is redirected to a generic log in page.
After entering valid credentials, a cookie is created, which has the IP address of the client, a public key, and other helpful info about the user, all base64 encrypted.
Any page requiring authentication after this point checks the public key and the requesting IP address. If the user's IP has changed, they are redirected to the login screen. If the cookie is tampered with, they are redirected.
The benefit of the above system is that a cookie can not be used on another machine (other than on the same LAN, but other measures check against man-in-the-middle attacks), as the IP address won't match.
The downside is that this method prevents the user's session from being extended server-side. In other words, a server-side script can't get information on behalf of the user since the IP address won't match.
This limitation makes sense under most circumstances, as it avoids allowing the server from "stealing" the user's cookie. However it also means that a Web Service can't be protected using the same authentication system, since requests will always come from the server's IP, never from the client (unless AJAX is used, which is a very limited usage of a web service).
What I would like is for the web service client (server-side) to pass the cookie to the web service server and have the web service server verify the authenticity of the cookie directly with the end-user's client.
My basis for this is how sites like Stackoveflow use Open ID to check log-in status at the browser level without the end-user being involved unless the check fails.
A quick wikipedia search leads me to understand that the underlying system involved is a protocol called Yadis.
So I would like to know if I am missing any pieces to this puzzle and if I'm leaving myself open to major security flaws:
User logs in as normal
Page user requests needs web-service
Page passes user's authentication cookie to web service
Web Service uses same cookie to request a generic "confirm authentication" page via user's browser. (without user seeing this).
"confirm authentication" page returns a "user logged in" message or the browser opens a new window with log-in page.
Upon receiving the "all clear" message above, web service returns any info requested by original page that user is logged in to.
Am I missing any details? Is Yadis just a name give to this idea or will I need to install something to make sure it works correctly?
The term "Yadis" can be a little murky because it's referred to different things over the years, but more than anything it refers to the discovery phase of the protocol. That is, it answers this question: given an identifier (like http://keturn.example.com/ or xri://=keturn*example or whatever), what is the authentication server to use for this user? What version of the protocol does it support?
Which, if I read your situation correctly, is not at all what you're trying to address.
What you describe, authorizing one web service to act on behalf of the server with another, is more the domain of what OAuth is meant to address. But if you're stuck with your client's currently implemented auth protocol, I'm not sure that helps you either. But it's probably worth a look, it's not dissimilar from the solution you propose.