This is a two part question.
The first question is. I am looking for a way to shield my php pages using one of these generic login boxes that appear without a real page / html form. Like this box here. What is the name of this? How is it done?
The second is. I want to CRON to visit this password page, and kick off a php script.
The dialog shows up for HTTP "Basic" or "Digest" authentication. This should not be used for anything serious. The "Basic" authentication sends passwords in the clear to the server. "Digest" is somewhat better, but there is no way for a user to detect whether the password he's supplying will be used for Basic or Digest (it might not even be clear to the user whether he's authenticating with an HTTP or HTTPS server).
Finally, most browsers offer only very obscure ways to clear a password for these authentication methods once it has been typed in. There is no way for the website itself to force a "log out" purge. So users who need to use shared/public computers will not be able to log out afterwards.
http://php.net/manual/en/features.http-auth.php
It sounds like you're referring to basic HTTP authentication.
If you're using the Apache webserver, use this documentation to help you set it up.
In general, URIs may contain authentication details and HTTP will accept these.
Form your URL like:
http://<username>:<password>#hostname/path
You may be better-off using CodeIgniter's built-in authentication facilities.
This is called HTTP Basic Authentication. Basic authentication can be invoked through PHP (as Timur suggested), or through Apache.
AuthType Basic
AuthName "Restricted Files"
AuthUserFile /usr/local/apache/passwd/passwords
Require user thomasreggi
As for the second part, you can use cron with wget or make cron run your php curl script. Here's a question which shows how to do this.
Related
There is a simple way to password protect a website directory using htacess and htpasswd files. More here: https://css-tricks.com/easily-password-protect-a-website-or-subdirectory/
But when it asks the user for a password it does so using a popup dialogue box at the browser level, see below:
Is is possible to communicate w the server via PHP so as to embed this interaction (i.e. requesting a username and password that works using the aforementioned technique) directly into a web page? If so, how would one go about this?
The "htaccess technique" uses a feature of the HTTP protocol, which is embedded HTTP authentication. This is a standardised protocol, which browsers implement with a standardised UI. You cannot change that UI. If you want a regular "in-page authentication" with a login form etc, you need to implement it entirely yourself using sessions and a custom HTML form.
That popup is provided by Apache (or installed webserver) to manage authentication on the first level. That allows you to be authenticated in all the webserver.
Authentication in PHP is only (by default) a webpage login.
The Server Authentication is locking, because if you don't have the username you cant do anything.
The PHP Authentication is configurable by you in all senses.
Both authentications are correct, but they are used for different things.
I don't know if it's possible, but if I don't ask I'll never know :)
I have the exact problem discuted in this topic. That's: I have some static files in some folders and I want only some users to see that content. That users are coming from a previous login.
Some possible solutions are discussed in that topic, but I have thought another possible solution. If I could send with PHP the Authorization HTTP Header, which contains the username and password of the user, and keep it persitent in subsequents requests (as I think it happens with the apache authentication). I would send that headers during my previous login, and then when the user would try to access to its directory, an .htaccess would check if he is a valid user.
I have tried to send the Authorization header with PHP with:
header('Authorization: Basic '.base64_encode($USERNAME.':'.$PASSWORD).PHP_EOL);
But they are only present for one request.
In .htaccess, I have checked that it's not possible to have an unique `Require user USERNAME', so I think it would be necessary to create an htpasswd file storing the same credentials than the ones the login process use, and then create an usual authentication configuration (basic or digest):
AuthType Basic
AuthName "Restricted Files"
AuthUserFile /path/to/htpasswd/file
Require user USERNAME
Thank you in advance
You could have an Basic or Digest HTTP authentification handled by Apache, with a simple "require valid user".
No apache can implement a lot of mod_auth variations, check for mod_auth* in this page.
So you can tell apache to authenticate on your database, or even to perform authentification with a custom code that you provide with mod_authnz_external.
External script support is good as you could implement a session authentification with a cache level (to prevent redoing the whole authentification for each requested resource), which is what basically happen with the default cookie based session (first authenticate, then just transfer the PHPSESSID, so we'll check the session exists).
I have thought another possible solution. If I could send with PHP the Authorization HTTP Header,
You couldn't
I am creating a website with multiple sections--admin, client, user, and anonymous--each user group having less access then the next. I am wondering what form of authentication would be best for my use?
I have heard the if you are just dealing with a websites then a web form is for you (because it's prettier). HTTP header authentication with PHP is said to get clunky/sloppy. htAcess is pretty much the hard core of various authentication methods I have looked up, but is it too much?
You're confusing things.
Your three options are basically two:
Use HTTP authentication
Do not use HTTP authentication
Whether it's handled by an .htaccess file or not is another matter. You can do HTTP authentication with Apache and PHP, and you can do non-HTTP authentication with Apache and PHP (though usually you do non-HTTP auth with PHP and HTTP auth with Apache).
Apache can defer the authentication to several backend and frontend modules (e.g. you can use CAS). Apache provides out-of-the-box (no dated sourceforge module...) for the following database backends: FreeTDS, MySQL, Oracle, PostgreSQL, SQLite 2/3 and an ODBC connector.
Personally, I dislike HTTP authentication. Usually a form will is more user friendly and you can provide links such as "Forgot your password?" and "Username not found".
I'd also go with implementing the authentication in PHP, because it's more portable (you can swap the web server).
Go for the form (a session really).
Nowadays it's the only option.
First off, for your application you should go for the simpler login form / session method. Because you want in-application user groups, it's only senseful to also use in-application authentication. Technically for the permission system it makes no difference which auth method is used. But you know, for simplicity and keeping all authorization stuff together...
The hatred against HTTP authentication is misgued, btw. It's the stronger authentication method, if you use HTTP Digest; which OTH is difficult to implement in PHP.
It's a usability nightmare only if you do it wrong. Practically a HTTP logon can be initiated with a login form as well. Using XMLHttpRequest can successfully trigger HTTP Authentication. And with a little more work (401 and new realm), pretty logouts are possible too. If no Javascript is enabled it falls back on the boring login dialog / readline obviously. But I've personally used a text-only browser for a while, and I tended to like that more.
Also, if your admin group is serious business (raw database access tools etc.), you should apply both methods. Make the admin interface separate from the application, apply login form and .htaccess restrictions. Better safe than sorry.
There is this PHP script on my website which I don't want people to be able to run by just typing its name in the browser.
Ideally I would like this script to be run only by registered users and only from within a Windows app (which I will have to provide). Can this be done ?
Alternatively, how can I protect this script so that it can only be called from a specific page or script?
Also how can I hide the exact URI from appearing on the address bar?
Thanks !
If you are running Apache for your webserver, you can protect it with a username/password combo using .htaccess. It takes a little configuration if your server is not already configured to allow .htaccess. Here are the Apache docs.
If you need authentication based on application-specific factors, you can put something at the top of your script like
<?php
if(!$user->isLoggedIn()) {
// do 404
header('HTTP/1.0 404 Not Found');
}
Do you have a question about how you would implement isLoggedIn?
You can also use mod_rewrite to rewrite URIs, and those directives can go inside your .htaccess as well. mod_rewrite can rewrite incoming requests transparently (from the browser's perspective) so a request for /foo/bar can be translated into secret_script.php/foo/bar. Docs for mod_rewrite.
However you decide to implement this, I would urge you to not rely solely on the fact that your script's name is obscure as a means to secure your application. At the very least, use .htaccess with some per-user authentication, and consider having your application authenticate users as well.
As Jesse says, it's possible to restrict your script to logged in users. There are a large number of questions on this already. Search for PHP authentication.
However, it is not possible to restrict it to a single application. It is fairly simple to use a program like Wireshark to see exactly how the program logs in and makes request. At that point, they can reproduce its behavior manually or in their own application.
There are a variety of different ways that you could go about securing a script. All have pluses and minuses, and its likely that the correct answer for your situation will be a combination of several.
Like mentioned, you could lock down the account with Apache...it's a good start. Similarly, you could build a powerful 'salt-ed' security system such as this: http://www.devarticles.com/c/a/JavaScript/Building-a-CHAP-Login-System-An-ObjectOriented-Approach/ If you use SSL as well, you're essentially getting yourself security like banks use on their websites--not perfect, but certainly not easy to break into.
But there are other ideas to consider too. Park your script in a class file that sits inaccessible via direct URI, then do calls to the various functions from an intermediary view script. Not perfect, but it does limit the ways that someone could directly access the file. Consider adding a "qualifier" to the URL via a simple get--have the script check for the qualifier or fail....again, not a great solution on its own, but one additional layer to dissuade the bad guys. If you have control of who's getting access (know exactly which networks) you could even go so far as to limit the IP's or the http referers that are allowed to access the file. Consider setting and checking cookies, with a clear expiration. Don't forget to set your robots file so the browsers don't stumble upon the script your trying to protect.
A while back my company did a membership app using Delphi on the front end, talking to php and MySql on the backend....it was a bit clunky given that we were all web application developers. If you're so inclined, perhaps Adobe Flex might be an option. But ultimately, you'll have to open a door that the application could talk to, and if someone was determined, theoretically they could dig through your app to find the credentials and use them to gain instant access to the site. If you're going the desktop app route, perhaps its time to consider having the app avoid talking to an intermediary script and do its work on the local machine, communicating the db that sits remote.
you can use deny access on .htaccess on a folder with a php authentification that will redirect to those php file
Using php I authenticate a user, then behind the scenes,they are then again authenticated a second time with a single .htaccess username & password. This would be the same for all users, but I would not want them to have to enter a username and password again and they would now be allowed to enter the password protected directory. I prefer not to use http://username#password:somedomain.com.
Any thoughts?
You should not do this.
Either:
Add code to your .htaccess protected directory to use your PHP authentication scheme and remove the .htaccess authentication.
Write a new PHP page/script through which your authenticated users will access all of the protected content. Move the protected content out of the web root, or use your .htaccess file to deny all access. Your script will be able to access the files, but users will have to go through the script to access them.
If you want to avoid multiple logins but need HTTP authentication, you can use only HTTP authentication for the actual login. This is because PHP can issue and respond to such headers.
http://php.net/manual/en/features.http-auth.php
This way the user receives a pop up, PHP can read it and respond accordingly and the browser will pass it with subsequent requests eliminating further prompts.
Note: This solution is not available to CGI versions of PHP.
Sorry, I do not believe this is possible (unless you want to use the username:pass#url scheme). You could write some ajax to do it behind the scenes, which would mean that the browser will remember the auth for that area (maybe, I have never actually tried it). But you would still need the username/pass regardless.
For the security of not transmitting the password in clear text on the browser (I assume you are using https to transmit the password over the network, or if your not you should!) I think it will be a little annoying for the user, but not a huge amount of hassle in my opinion.
Of course you could do the authenticating on that other folder in PHP, which would solve the issue, or put all your protected code in the one place with the one HTTP auth, but I assume you dont want (or cant) do this.