I am working on windows and for now I have Http Basic authentication with following .htaccess file:
AuthName "Restricted Area"
AuthType Basic
AuthUserFile D:\\some\\windows\\path/.htpasswd
require valid-user
and following .htpasswd file for user "test" with password "test" (created using http://www.htaccesstools.com/htpasswd-generator-windows/):
test:$apr1$EUhLJ8Ye$LpBIbzDcBXY.80pH53oN2/
This works, I am able to enter correct username and password and I gain access.
But as I am not using SSL I would like to use Digest authentication (to avoid sending password in plain text to server). I changed line AuthType Basic to AuthType Digest but it is not working anymore - even if I am typing correct user and pass I cant gain access.
Probably I should encrypt/hash password in .htpasswd using different algorithm but I cant find it...
If you want to use digest authentication, you'll have to create new password files. Those for digest auth will have a slightly different format that that used for basic auth. Typically, apache comes with tools for doing this.
Look out for the command line programs "htpasswd.exe" and "htdigest.exe". You need to use the second one for generating password files for digest auth. Use it like this:
c:\path\to\htdigest.exe -c c:\some\windows\path.htpasswd_digest realm username
You'll only need "-c" the first time you issue the command, if you only add new users to an existing file, it's like:
c:\path\to\htdigest.exe c:\some\windows\path.htpasswd_digest realm another_username
"realm" should be the same value you used in your apache config for AuthName.
Oh, and obviously, don't forget to update AuthUserFile in your apache configuration...
Related
I have a web app with a setting page that I would like to protect with a password so that unless the password is correctly entered the user cannot change any of the settings.
To add a password for a page on your website, you’ll need to modify the .htaccess and .htpasswd files on the server. Take a look at this link for the full details.
Basically you need to do these two things:
Modify (or add) the special text file on your server called .htpasswd, to contain the username and encrypted password separated by a colon on a separate line.
If you have SSH access, this can be done automatically using the htpasswd utility:
htpasswd -c .htpasswd ben
Otherwise you can modify/create the file manually, and handcraft the username/password using an online password encryptor. The linked-to site suggests these three:
4WebHelp's online .htpasswd encryption tool
Alterlinks .htaccess password generator
htmlite's htpasswd encryption page
As an example, for a username of ben and a password of password12345 you would use this line:
ben:51CbcBM13fOMo
Modify (or add) the special text file called .htaccess, in the folder where the settings page you want to protect resides, to contain the following:
AuthUserFile /full/path/to/.htpasswd
AuthType Basic
AuthName "Protected Settings Page"
<Files "mySettingsPage.html">
Require valid-user
</Files>
Of course, /full/path/to/.htpasswd should be replaced with the full path to where the .htpasswd file resides on your server.
Likewise, replace mySettingsPage.html with your own settings page name.
Note that the AuthName string can be changed to suit.
I have been requested to setup a test site written in php, on a unix box. I have been given the site files and it is loading fine but I need to close it off from anonymous access. Is there a setting in Apache server that allows this to be done in the same way that Windows Authentication would in IIS. I understand that a login page could be added to the site but I am not a php developer and wanted to take advantage of existing functionality if it's there.
Thanks.
A simple solution would be to add an .htaccess file with something like this in your webroot:
AuthUserFile /<path>/.htpasswd
AuthType Basic
AuthName "Your Auth Name"
Require valid-user
Then you would need to add a .htpasswd file with your login credentials.
To add a .htpasswd file you could open your terminal and execute the following command:
htpasswd -c -b .htpasswd username password
The above will create a file name .htpasswd with username/password as login in the current directory.
Reference: Password Protection with .htaccess & .htpasswd
I have a website admin area I want to protect with a password..
so inside the admin folder I put an .htaccess and .htpasswd files containing this:
.htaccess:
AuthUserFile C:/wamp/www/website_project/admin/.htpasswd
AuthName "Restricted Area"
AuthType Basic
Require valid-user
.htpasswd: (generated using an online tool)
admin:sOSDxAdJI4xx2
When I go to the admin folder, a popup is shown where I need to insert username and password... so until now its working fine, BUT no matter if I insert a correct password or not I get the same popup again when I hit 'enter', I can never access the folder...
Any suggestions?
Based on the AuthUserFile line, it looks like you're using Apache on Windows, which has a different default password encryption algorithm than other platforms. Try using the htpasswd command-line tool to generate the password and see if you still have the same problem.
I have a CakePHP Application which I want to protect with a password. The tricky thing is, that all files/locations should be only accessible with a password EXCEPT one specific Address (a function withing a CakePHP-controller)
The Address is like that:
http://example.com/MyApp/MyController/MyFunction?MyParam=MyValue
All other locations should be only accessible with a password
http://example.com/MyApp/MyController/MyOtherFunction
http://example.com/MyApp/MyController/MyOtherFunction
http://example.com/MyApp/MyOtherController/MyOtherFunction
Well, I tried it first in the root .htaccess-File, but the whole rewrite-thing of CakePHP makes it very difficult and in .htaccess-Files are no <LocationMatch> directive allowed. So I tried it with <FilesMatch>, but the real File is always the same: index.php. mod_rewrite rewrites all Addresses to
http://example.com/MyApp/app/webroot/index.php?url=$1
In the next step I tried it in the apache-configuration and put there this section
<LocationMatch ^/MyApp/MyController/MyFunction.*>
AuthType Basic
AuthName "Secure Area"
AuthUserFile /path/to/.htpasswd
Require user MyUser
</LocationMatch>
Well the regex matched, but it was the wrong way. It protects MyFunction but not the rest.
Are you using .htpasswd? You might be better using Cake Auth, then you can do this in the appropriate controller:
function beforeFilter() {
$this->Auth->allow('MyFunction');
}
I have a domain that will be accessed by a small, private group of people. So I want to control access via authentication.
The domain has a collection of applications installed that each have their own sub-domain. Eg: domain.com, app1.domain.com, app2.domain.com, app3.domain.com
I'd love to have a single sign-on solution so they don't have to authenticate themselves for each application. Also, the applications are written in different languages (PHP, Python and Perl) so authenticating users through an Apache module is ideal.
I am new to digest authentication, but it seems like a good solution. I have used htdigest to create my users. I have configured my domain and sub-domains (See below).
If I go to the domain or any of the sub-domains it will prompt for a username and password. If I enter a correct username and password, it will authenticate me and the page will load. However, if I go to another sub-domain, it will ask for me to enter a username and password again. If I enter the same username and password, it will work.
So the password file is OK, and authentication is OK, but the problem seems to lie in the configuration of the AuthDigestDomain.
I have searched all over the net to find an example of using Digest authentication on multiple domains, but I cannot find a specific example that solves my problem.
I am hoping someone here can assist. Do I put the same authentication information in every Directory? Should I be using Directory or Location or Files? Have I missed something all-together?
Thanks in advance!
Below is an example of my Apache config for domain.com:
<Directory /var/www>
AuthType Digest
AuthName "realm"
AuthDigestAlgorithm MD5
AuthDigestDomain / http://domain.com/ http://app1.domain.com/ http://app2.domain.com/ http://app3.domain.com/
AuthDigestNcCheck Off
AuthDigestNonceLifetime 0
AuthDigestQop auth
AuthDigestProvider file
AuthUserFile /etc/apache2/.htpasswd-digest
AuthGroupFile /dev/null
Require valid-user
</Directory>
And here is an example of app1.domain.com:
<Directory /var/lib/app1>
AuthType Digest
AuthName "realm"
AuthDigestAlgorithm MD5
AuthDigestDomain / http://domain.com/ http://app1.domain.com/ http://app2.domain.com/ http://app3.domain.com/
AuthDigestNcCheck Off
AuthDigestNonceLifetime 0
AuthDigestQop auth
AuthDigestProvider file
AuthUserFile /etc/apache2/.htpasswd-digest
AuthGroupFile /dev/null
Require valid-user
</Directory>
To baffle things even further, this works when using IE6, but not Firefox or Chrome. Is it the clients not sending the authentication properly, or is is the server not sending the correct credentials?
I have also been reading up on RFC 2617 and written the authentication headers using PHP to ensure that the request/response challenge is correct. This hasn't helped at all!
Most browsers do not respect the Digest "domain" directive and will not resend credentials for other URIs. As far as I know, Opera is the only browser that honors it.
For Opera, the server(s) must respond with the same "realm" string for each URI in the domain list. In other words, if domain="/test /example", the server needs to send "Test Realm - example.com" in the WWW-Authenticate header for both of those URIs. I assume Opera does this because it stores H(A1) instead of the actual password for security. Read into RFC2617 for more on this.
Here's my cross-browser solution to this problem: http://travisce.com/arest/
I have no experience with something like this myself. But I just took a look at the Apache documentation and found this:
The AuthDigestNonceLifetime directive
controls how long the server nonce is
valid. [...] If seconds is less than 0
then the nonce never expires.
So it seems to me that 0 seconds (the value you are using) is either illegal or really tells Apache to expire the nonce after 0 seconds which would exactly explain the behavior you are geting.
Could a wildcard on the AuthDigestDomain help?
*.domain.com