I've been using HTTP authentication through .htaccess files every time I've needed quick and dirty password protection for a complete directory (most of the times, in order to hide third-party apps I install for private use). Now I've written some PHP code to replace local passwords with OpenID. That allows me to get rid of HTTP auth in my PHP sites. However, I'm still trying to figure out a trick I can use in non-PHP stuff (from third-party programs to random stuff).
Apache does not seem to support authentication with custom scripts by default (whatever I do, it should work in my hosting provider). That leaves the obvious solution of using mod_rewrite to route everything though a PHP script that checks credentials and reads the target file but 1) it looks like a performance killer 2) it will interfere with dynamic stuff, such as other PHP scripts.
I'm wondering whether there's a way to tune up the router approach so the script does not need to send the file, or if I'm overlooking some other approach. Any idea?
I think your mod_rewrite approach would be the only way to do this - but instead of using readfile() (as I guess you are, based on what you say about it will interfere with dynamic stuff, such as other PHP scripts) you can just include() them, so that raw files are written straight to output and PHP code is executed.
You may use PHP HTTP-AUTH http://php.net/manual/en/features.http-auth.php
If OpenID is all what you need consider usage of mod_auth_openid for apache
Related
I want to separate out the API calls my site makes to another install as the site has become big and buggy by having everything together. I would like to know what ways are there if any to make two sites communicate when they are on the same server.
I originally was thinking I could get the client-facing site to just include the models from the API site through a custom loader for CodeIgniter, but I am currently leaning towards wanting the API site to take advantage of Laravel which would obviously scrap directly loading them.
Currently I have some calls which are using CURL to POST requests, is this the only way? I was hoping to drop the HTTP calls in favour of something more direct.
As I said in my comments to the question, I'm definitely no expert on this kind of stuff, but my original thinking was that IPC-style stuff could be done, maybe using names pipes.
PHP does allow for this in its POSIX and process control functions. Simply use posix_mkfifo to create a named pipe and then you should be able to use fopen, fread, etc. (along with the stream_* functions if you need to) to write to and read form the pipe. However, I'm not sure how well that works with a single writer and multiple readers, and it's also probably quite a large change to your code to replace the HTTP stuff you currently have.
So the next possibility is that, if you want to stick with HTTP (and don't mind the small overhead of forming HTTP requests and the headers, etc.), then you should ensure that your server is using local sockets to cut down on transport costs. If your web site's domain name is the same hostname as the server itself this should already be happening (as your /etc/hosts file will have any entry pointing the hostname to 127.0.0.1). However, if not, all you need to do is add such an entry and, as far as I'm aware, it'll work. At the very worst you could hardcode 127.0.0.1 in your code (and ensure your webserver responds correctly to these requests), of course.
I am setting up a little page with a quite simple login-system via PHP Sessions. Business as usual: the correct Username/Password combination sets $_SESSION['login'] to true. When opening /page1.php or /page2.php a few lines of PHP will check the login state.
As I would like to have it nice and secure I would also like to keep unauthorized visitors from accessing files other than .php, for instance my javascript or CSS files.
I thought of a few ways to do that:
htaccess/htpasswd is the most obvious option, but I am searching for something more fancy. You know, having a custom UI etc...
mod_rewrite could redirect everything everything to a PHP-file like fetch.php?url=script.js, which could then execute my PHP before echoing the content of script.js. But this way I would have to mess around with MIME-types and it would bypass all other kinds of htaccess protection. Seems like a security risk to me.
declaring a auto_prepend_file in my .htaccess would do a similar job, yet it does not create any MIME-type problems or security issues. I couldn't really get it to work on my server, probably deactivated by my server-host.
Do you have any additional idea? I assume this is a common problem, so there should be a solution for it. Thanks in advance!
To keep it consistent (not have one login via php and one via basic auth) you'll need to run all your assets through php. However I highly recommend against this from several performance reasons:
Incurrs lot more to latency server files via PHP vs. the server daemon (nginx/apache)
Add unnecessary load on server CPU and memory
Wastes time locking up processes that could be use to serve up more requests
You'll never be able to use a CDN with this logged-in only requirement for
I think the main suggestion in my answer is to rethink what you're doing that requires you're client to be logged in to access CSS and JS assets. Are you putting passwords in the JS or something? If so, I recommend deeper evaluation of your architecture over passing all assets through PHP.
I am now having download links on my server that directly points to files. I have a set of quite complicated rewrite rules but they don't affect what I am asking for.
What I want to do is to count the number of downloads. I know I could write a PHP script to echo the content and with a rewrite rule so that the PHP script will process all downloads.
However, there are a few points that I am worried about:
There is a chance that some dangerous paths (e.g. /etc/passwd, ../../index.php) will not be blocked due to carelessness or unnoticed bugs
Need to handle HTTP 404 Not Found response (and others) in the script which I prefer letting Apache handle them (I have an error handler script that rely on server redirect variables)
HTTP headers (like content type or modified time) may not be correctly set
Using a PHP script doesn't usually allow HTTP 304 Unmodified response so that browser caching will be useless, and re-download can consume extra bandwidth Actually I can check for that, but would require some more coding and debugging.
PHP script uses more processing power than directly loading the file directly by Apache
So, I would like to find some other ways to perform statistics. Can I, for example, make Apache trigger a script when certain files (in certain directories) are being requested and downloaded?
This may not be quite what you're looking for, but in the spirit of using the right tool for the job you could easily use Google Analytics (or probably any other analytics package) to track this. Take a look at https://support.google.com/analytics/bin/answer.py?hl=en-GB&answer=1136922.
Edit:
It would require the ability to modify the vhost setup for your site, but you could create a separate apache log file for your downloads. Let's say you've got a downloads folder to store the files that are available for download, you could add something like this to your vhost:
SetEnvIf Request_URI "^/downloads/.+$" download
LogFormat "%U" download-log
CustomLog download-tracking.log download-log env=download
Now, any time something is requested from the /downloads/ folder, it will be logged in the download-tracking.log file.
A few things to know:
You can have as many SentEnvIf lines as you need. As long as they all set the download environment variable, the request will be logged to the CustomLog
The LogFormat I've shown will log only the URI requested, but you can easily customize that to log much more than just the URI, see http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#logformat for more details.
If you're providing PDF files, be aware that some browsers/plugins will make a separate request for each page of the PDF so you would need to account for that when you read the logs.
The primary benefit of this method is that it does not require any coding, just a simple config change and you're ready to go. The downside, of course, is that you'd have to do some kind of log processing. It just depends what is most important to you.
Another option would be to use a PHP script and the readfile function. This makes it much easier to log requests to a database, but it does come with the other issues you mentioned earlier.
There are ways to pipe Apache logs to MySQL, but from what I've seen it can be tricky. Depending on what you're doing, it may be worth the effort... but then again it might not.
You can parse the Apache log files.
Apaches mod_lua probably is the most general, flexible and effective approach to hooking own code into the request processing inside apache. Usually you chose that language for the task that offers the most direct approach. And lua is much better in teracting with c/c++ than anything else.
However there certainly are other strategies, so be creative. Two things come to my mind immediately:
some creative use of PAM if you are under some sort of unix like system: configure some kind of dummy authentication requirement and setup PAM for processing. Inside the PAM configuration you can do whatever you like. The avantage: you get requests and can filter yourself what to count and what not. You have to make sure the PAM response does not create a valid session though, so that you really get a tick for each request done by a client, not only the first one.
there are other apache modules that allow to do request processing. Have a look at the forensic module or the external filter module. Both allow to hook external logic into request processing. You will need cli based php configured for that.
Nowadays, Developers and Professionals tend to use PHP templates because of two reasons. They are manageable and secondly, we don't need to advertise our technology as there are no question marks and .php extensions within the URL.
But how to make non-advertisement of your technology possible while sending a jQuery Ajax request to load a PHP file in a div. I mean we would, have to write $.get('phpfile.php') within the script and one can say that voa he is using PHP hmmmm.
Simply, I want to ask is there is any way of loading a PHP through request without advertising your technology as above told.
Some coding will be honored.
But how to make non-advertisement of your technology possible while sending a jQuery ajax request to load a php file in a div. I mean we would, have to write $.load('phpfile.php') within the script and one can say that voa he is using PHP hmmmm.
I don't get it. jQuery doesn't know about PHP files. If your website has 2 "public pages" www.example.com and www.example.com/foo, then you can access to the /foo page from the homepage with something like $.get("/foo"). Here I use AJAX, jQuery, and nobody knows if my page use PHP or whatever.
Then, you should look for mod_rewrite has explained by verisimilitude, but rewriting url is not the unique solution. Have a look to this site http://builtwith.com/ and enter a random url. Web servers send, by default, a lot of data about themselves, so you should avoid that behavior too if you want to "hide" the technology used. Have a look here http://xianshield.org/guides/apache2.0guide.html. It's "a guide to installing and hardening an Apache 2.0 web server to common security standards.". You may find useful information in there.
Edit
And also, "PHP templates" are not related to pages URL at all. For example, you could have multiple URL which use the same "PHP template".
mod_rewrite is the best answer for all your predicaments. Why not use it? The URL phpfile.php in your above code could be rewritten to achieve the obfuscation...
#pomeh. Good point.
See. two things can be done here.
1) Disable the APACHE signature. In the default configuration of Apache, any page served through it will contain a full signature of the server. Server signatures contain valuable information about installed software and can be read (and exploited). Therefore is it safer to turn off this behavior. This is how you do it. Open Apache’s configuration file (httpd.conf or apache2.conf) and search for ServerSignature . Set it to 'Off'. After that search for ServerTokens and set it to 'Prod'.
2) Set "expose_php" in php.ini to false: Exposes to the world that PHP is installed on the server, which includes the PHP version within the HTTP header.
3) There are some php obfuscators available which also may be used. I will not recommend them since I've not personally tried them.
There are ways and means beyond these to hide the "technology". By default, a php enabled APACHE web server processes and interprets all files with .php extension. But we can bind any weirdo extension to hide the technology to be processed by the server..
I guess verisimilitude and pomeh already answered this question.
All web servers send information about themselves over the internet. You cant hide that.
If you want to hide file extensions, like 'aspx, php, asp, html' then you will need to use mod_rewrite under Apache or something like URL Rewrite under IIS7.
You can also set default documents under IIS7. This really only works once per web folder. For example you can set default.htm as one of the default documents. When a visitor goes to your website they type www.domain.com and they get a web page. That visitor is actually looking at www.domain.com/default.htm
I am seeking a simple and best solution to manage user logins (username & password) in a private network (localhost) web page without setting up MySQL or any such database systems? I am running Apache with PHP. It will be helpful if anybody give a PHP demo.
Depends on your webserver. Assuming apache, htpasswd for basic auth could be all you need.
Authentication, Authorization and Access Control gives the information you need to get started.
If you are using localhost, then wouldn't everyone have access to the filesystem?
I think the simplest solution is .htaccess though.
There are other solutions like that, but I can't find nicer links right now:
http://webscripts.softpedia.com/script/Authentication/AuthMan-Free-42216.html
http://www.phpkode.com./scripts/item/passwdauth/
http://www.hotscripts.com/listing/htaccess-manager-lite/
http://www.hotscripts.com/listing/needlock-access-management-system/
http://www.hotscripts.com/listing/dirlock/ (Ooops. Too many hotscripts links. So just saying: not affiliated with that. :] And certainly not endorsing it!)
Anyway. These scripts store usernames and passwords into a .htpasswd file. This can be used independently from the PHP script. .htaccess and .htpasswd is common authentication scheme for Apache webservers. See this tutorial: http://www.javascriptkit.com/howto/htaccess3.shtml or the Apache manual: http://httpd.apache.org/docs/2.0/howto/auth.html
You could use the class itself for authentication, but it doesn't look very current. The login management tool might be useful to you. (But again: there are probably easier ones to find.)
Have a look at www.mykonosphotographs.com/musas/
I'm still in the process of writing a download page, but I can email you the script if you're interested. Use the contact from on the site.
It's a major modification to a single-password system written by someone else, and I've added lots of extra functionality which you can use or not, as you like.
Currently free. It won't be as soon as I've got the downloads page sorted! ;-)
Edit - too late! The downloads page is now sorted.
New URL - http://www.myksoftware.com
nope.
unless you want to save all information to files (like csvs)
but this could be a security threat if anyone got access to the files (which is easier than gaining access to a database)
php doc for reading csv file
You can hide almost anything by various means.
For example, if your webspace provider permits it you can place files outside of your root directory. You can place files in a directory with some weird name like "jdf83usadj300p", with no link to them other than in php, which is parsed by serverside software without the clientside software ever seeing it. You can place passwords in a config file, if you call it something like "config.php" and make the first line:-
; <? php die(); ?>
Only an idiot would use the various javaScript "protection" methods out there like making the password the name of the next file. .htaccess can be cumbersome and can put people off. Far better make it attractive using server-side software.
If passwords are likely to be attacked, ALWAYS encrypt them. NEVER pass passwords from one page to another by GET method unless already encrypted. POST is more secure. md5 encrypting for most purposes is good, with encryption in-built in PHP and many algorithms out there freely available for javaScript. SHA-256 is almost the best there is fo almost any purpose. I don't think the US DoD or the UK MOD would be satisfied with it, but your local sports club's website (or similar) isn't exactly going to be a high-profile target for hackers.
Incidentally, blasteralfred, I sent you an email update. Hope you got it. Good luck!