I've written a generic file system viewer in php and I'd like to add context highlighting. Geshi looks good for this, but appears to require me to send in the language I want to highlight the code in.
Any existing methods on how to determine the scripting language of a given file by contents and/or location?
I have the mime type from:
$finfo = finfo_open(FILEINFO_MIME_TYPE);
$mime_type = #finfo_file($finfo, $full_path );
That lets me know it's text at least (I allow download of non text too).
I'm thinking that parsing the bang line/file extension or looking for simple tags like php would get me a good chunk of the way for things like perl/shell scripts/php.
I also have the path to the file, as these files are coming directly off the source servers so path based rules may work for things like /etc/httpd/conf.d/*, /etc/passwd.
Perfect accuracy isn't really a problem as I'll allow the user to override the language used for the syntax. I just want to provide a low overhead educated guess to start with without writing this from scratch.
One other caveat. Some of these files can be > 150mb so I'd like to only read part of the file although I could just turn off this feature for large files if needed.
If you can call out to an external program, try the Linux file command.
I'm surprised noone pointed me to prettify.js from google code. It will probably do everything I need it to, client side.
Related
I know JavaScript or CSS for expample can be "compressed", "simplified" in order to be loaded faster. After simplifying they are difficult to be read by humans... and this is exactly what I need.
Is there anyway to make it automatically? Rename all variables to short random strings and make it all hypercompressed. I don't think it is a fool thing because I have seen this lot of times in javascript. The idea is to conserve the original source and upload the minified one.
There is no need for doing this. The Server reads the file, and the file never gets transferred to the user.
Therefore, compression is useless because there is no bandwidth saved.
CSS & JavaScript does however get transfered to the user, and therefore they can see it. A user can never see PHP unless you've done something wrong on your server. But then you need to worry about totally different things than compression.
If you want to compress it, this is basically useless, since you have it on the server and only the output gets transferred to the client.
If you want to make the code more difficult to read for other human beings, you're looking for something which is called an obfuscator.
There are a few php obfuscator engines out there, p.e.
http://www.codeeclipse.com/
http://www.truebug.com/
http://www.raizlabs.com/softwarephpobfuscator/
I have searched around a bit, and have not really found a professional type response to how to have secure fileupload capability. So I wanted to get the opinion of some of the experts on this site. I am currently allowing upload of mp3s and images, and while I am pretty confident in preventing xss and injection attacks on my site, I am not really familiar with fileupload security. I basically just use php fileinfo and check an array of accepted filetypes against the filetype. For images, there is the getimagesize function and some additional checks. As far as storing them, I just have a folder within my directory, because I want the users to be able to use the files. If anyone could give me some tips I would really appreciate it.
I usually invoke ClamAV when accepting files that can be shared. With PHP, this is rather easily accomplished with php-clamav.
One of the last things you want to do is spread malware around the globe :)
If you can, do this in the background after a file is uploaded, but before making it public. A quirk with this class is that it can load the entire ClamAV virus definition database into memory, which will almost certainly stink if PHP is running under Apache conventionally (think on the order of +120 MB of memory per instance).
Using something like beanstalkd to scan uploads then update your DB to make them public is a very good way to work around this.
I mentioned this only because the other answers had not, in no way did I intend this to be a complete solution. See the other answers posted here, this is a step you should be finishing with. Always, always, always sanitize your input, make sure it's of the expected type, etc (did I mention that you should read the other answers too?)
"malicious" files are not the only way to hurt your server (and if your site is down, it hurts your users).
For example, a possibility to hurt a server would be to upload a lot of very small files :
it would not use all the space on the disk,
but could use all available inodes...
...And when there is no free inode left, it's not possible to create any file anymore ; which, obviously, is bad.
After that, there is also the problems like :
copyright
content that is not OK to you or your users (nudity ? )
For that, there's not much you an do with technical solutions -- but an "alert the moderator" feature is oftne helpful ;-)
No, because this could easily be spoofed. There's an article that describes how a server could be attacked by uploading a 1x1 "jpg file" and how to prevent it. Good read.
The first thing to do would be to disable execution of any server side code (e.g. PHP) in that directory via server configuration. Setting up a whitelist for MIME types (or file extensions, since your server uses those to figure out the mime type in the first place) and only allowing media files (not HTML or anything) will protect you from XSS injections. Those combined with a file type check should be quite sufficient - the only thing I can think of that might get through those are things that exploit image/audio decoders, and for spotting those you'd need something close to a virus scanner.
To start with the "file-type" ($_FILES['userfile']['type']) is completely meaningless. This is a variable in the HTTP post request that can be ANY VALUE the attacker wants. Remove this check ASAP.
getimagesize() Is an excellent way to verify that an image is real. Sounds files can be a bit more tricky, you could call file /tmp/temp_uploaded_file on the commandline.
By far the most important part of an uploaded file is the file's extension. If the file is a .php, then you just got hacked. It gets worse, Apache can be configured to ignore the first file extension if it doesn't recognize it, and then use the next extension, so this file would be executed a normal .php file: backdoor.php.junk. By default this should be disabled, but it was enabled by default a few years ago.
You MUST MUST MUST use a file extension White List. So you want to force using files like: jpg,jpeg,gif,png,mp3 and reject it otherwise.
if exiv2 can't remove the metadata its probably malicious or corrupted in some way atleast. following required exiv2 be installed on your unix system. Unfortunately, this might be dangerous if the file contains malicious shell code. not sure how sturdy exiv2 is against shell exploits, so use with caution. i haven't used it, but i've thought about using it.
function isFileMalicious($file)
{
try{
$out = [];
#exec('exiv2 rm '.escapeshellarg($file).' 2>&1',$out);
if(!empty($out)){
return false;
}
}
catch(exception $e)
{
return false;
}
return true;
}
I'm developing a website that will be available in different languages. It is a LAMP (Linux, Apache, MySQL, PHP) setup, and it makes use of Smarty, mostly for the template engine.
The way we currently translate is by a self-written smarty plugin, which will recognize certain tags in the HTML files, and will find the corresponding tag in an earlier defined language file.
The HTML could look as follows:
<p>Hi, welcome to $#gamedesc;!</p>
And the language file could look like this:
gamedesc:Poing 2009$;
welcome:this is another tag$;
Which would then output
<p>Hi, welcome to Poing 2009!</p>
This system is very basic, but it is pretty hard to control, if I f.e. would like to keep track of what has been translated so far, or give certain users the rights to translate only certain tags.
I've been looking at some alternative ways to approach this, by either replacing the text-file with XML files which could store some extra meta-data, or by perhaps storing all the texts in the database, and retrieving it there.
My question is, what would be the best way to make this system both maintainable and perform well with high user-traffic? Are there perhaps any (lightweight) plugins I could take a look at?
You could give a shot at gettext. It is the way it is done in most C/C++ linux applications and it is an extension to PHP too. The idea is not very different from what you're already doing, but there are tools that ease the mantainance of translations (i.e. poedit).
For user rights to translations, gettext won't be of much help, I think you'll need to do it on your own or look at some frameworks if they have smarter solutions.
Maybe taking a look to gettext lib could help you get some hints http://php.net/manual/en/book.gettext.php hope it helps!
You will need to have a table in your database that you can use to store strings of text, each with an composite ID. the composite ID will be made up of language ID and text node ID.
You will need to give the user a chance to select a preferred language. You should make sure that you either have a default "this has not been translated" for every language you use, or a default language that your entire site can be vied in.
For every bit of text with in your web site, rather then store the text with in the page, you just assign it an ID.
When serving the page, look up the text node ID and preferred language ID and load that string of text, or the string for the default.
in our project, http://pkp.sfu.ca/ojs, we use XML files to store translation key-value pairs. Browse our code: http://github.com/pkp/pkp-lib/blob/master/classes/i18n/PKPLocale.inc.php
We use that class to read the XML files for each locale and in our code we use Locale::translate('locale.key.name');. Similar to gettext, but using an XML file for easier updating.
Looking around at web stuff today I came across this website: http://translateth.is/
It looks simple to use... copy paste in some javascript.
This is a string (see below, after the dashed line) in a database.inf file for a free program I downloaded that lists some websites.
The file is plain text as you can see , but there is a string after it that looks base64 encoded (due to the end chars of ==). But b64_decoding it gives giberish.
I wanted to decode it so I could add to the list of sites it had (the program lists a bunch of sites and data about them which I can read in the GUI) and to do that I need to decode this, add to it, and re-encode it.
I think the program uses .net since I think the .net library was required on install, but I know nothing of the original source language.
I am using php to figure out if there is a simple way to read this. I have tried using unpack, binhex, base_convert, etc as I suspect the file is binary at some level, but I am lost.
Nothing illegal, just wanting to know what it is and if I can add a few things to it to make it more useful for me.
here is the file - any ideas how to decode and recode this for playing with?
Site List
file size: 62139
db version: 13
generated: 2010-04-27 11:53:40
eJztPWmT27iVnze/gjVVk56pXXXz1BW3XW2PPXaNr/iIa69SUSIkMaZIhaQstys/fgHwEIiDBEjQk6Q2lUraeuAD8PDwbgAPtkl6eBoZsX8At1enDKRXRvGfL350gj/9uEmBn4MVAqFGP14Z+f0R3FoP//CA+Rb9ddXj26OfZYJ+EeicpEHrt/5V/2/XA75FDTjzlf7WvlL/NgWXnlW/BQc/jPjzxaAfMUzU7+Xr7m+pj7cVZ/C63pa8Iewa/e+299fbMM3yuv8+fa8wCs5Cy/W9EmwLztfU51Eb2SKZoUe9v458gmq9+l4hFDyiS/W9Ei0Z52tO5/W8+VQ3aGwipvcjIRGUMPmnfN8XE40qCFKABSaFpgQg2ggGARtwB9D55SbM77lfIkCxGIIvsxw2460jBrRxwbfwyJdVEFB2eSERTaTstP4r2OQsG+RhHoEfL7+XOGy6d9yObKaKwE/zJo4eCFYNDD0QhJsIXHD0RHAZRV8EzF6WRQCXkU/ECnDBIUSwB37A8oEsgg3kuF2S3rOCtASwCNq1H4ECCYVCuTT4mRlDUwH2QNDUgT1HcFGDfUewIobQjaBVGdIYkMqoV0I8h2gIgqZK7DmCi1bsOYKVcB25CFp1I38djAY6wXqeokg8Enk8qEWSXg0eT4GHGFFPPMk5BmkHn8rgaVoOA+ZVStCaTgPoo2U8eBzD6bNdHUHci38Ycwi14Xk2F0C7aCpZh3Vv1BAQQ1BFUDDdAATk9PsjuBiW/WjQGIUqglPamACBAJpBH9+9JIwFsbkE27GaXhoBXkZiHKoIzmCdhTnH9VBEsKrHoIoAfd0gZB8i8pexAnQpGMhBySndsIKmAnDsJc6GXocJX1RBQJfJViwkgaEfAmIMqgjI0fcbwTo55cINLYOg0BsXPL1GQGrnnkQMQA65hvRWxQgoDAHINlxbBQHS8JiHSUz6nswQiHZXvRCUVGzi4SNpV98NDCoIstPh4BPeR8scWkdA4FFEkOVJo38JBBSGz+AehSWzKwZDBekwe8s5EHj6IVhdMHQioN3AJM5BnHPWocQtsSFXTSTqCPAc1klAhWLUEAyaAmpGzKIfghx87UuDQqYMQFBFNGoMiggu1JcmImP5VpGD8BKW4AcV2udQtV2FZCqAiwCOIQeHYwSBxotfbq/uChTGL362Xyd+GhhRsgtjOzutD2EOO7g+7o9XD//wbw+yI9iEfrRCmB5KffbgpvENxLGN/F328O/P/axo//e7U54U3/z9wU0Bhc0wDNk+D2+4aC/wS+MMpA+DZHM6QIa83oH8aQTQn9nj+9eQVj9BYtd5qZ//2/zfa0ymGhX6usaFsicduOrMC4sLf13j2oZxmO0f3tQzwCKYnEbZAlEYt0HzsvkfkA1g+xTswiyH/gKmVBbu4tOxaNiAXDAXQrpjanW08jI149b4oQzU/fCn/4H/6cRQKRkKB6knJDHhbUahqTaYJApob9IYahNUEgVUDjSKWl/88Kd6ZUoCXygeJDEoludwX466sZQ1nPokSpLPcKtb9UZ7f9psoEeGgi33xtsELm7QRFJ/ATGVDnXRcfmPolsSQjQkMTx8C2IDTb3Z510QoC65X5C8KMVjDSeTomsjlSizPGU+Uhc6ztYmEdWpVbmh6cS2paQXiahIHMlgiVqwRNJYSmpbAkRVGkkGVZHd4eNBCR4ZHDgrxUeB81IyOIr8FB9JkaJCO51mdCTpUSx2s/fjHXhom+Z8YjoT2zKsxdKyl5YHBT3R4A8PbioF/JBWxjdhHICvaKc+Ovo7cIsVBKt8uc10KFs+Xo62rTb+R6g3jZdkM0IkSCpm1GBV8qQ1TC8Tm43GxNfK9YRZZUz+u54VnKrx5pQ3W5NzbqhwipwNjc4o88s/rRrhc5AC4z45GRs/NooGRgzORmUVkEgsrjTmLWsFHGImNPOBPS0FKqJNK3l++FcebRaHxyPIh9kgNTK+QXOxRGRsAGohDlBCwv+XNwb+E9os1eIbe7iv1wBUjNFqEHB+t5vYwqwDj82RdLOJucCSbrq05kvPVJB0aGdf413EdzCoBkLpdhdFydl4/uHVS0LQ8aUbjbGPF1FERAc7EBLuA7Gzy6FDnXpN2JCPHjW2PyN9ur/hOBH4o+Kn1EdbBH8FZc4BHNYgvX0Nzv/+Cv85RHoMkhp15EZsj3du6ktUlyd0UERSWjIUGMpIyCe4w5Pzdf0Zcl6uwzgGKeJQUmKgf0t0IuVHcUSPijlOKuAhpuUlJT3MuMTjoTdaH1ten+2t046vckOsJsF5me/FvRQSWQa+BO0xB19JWcRYT1gLw7KgObw05wp6ohhndiMyhRtwCRuYrxooLH00w8dLdGmgFfu224ptCPpq8NU63ARJp5ynvxkizT8MkebvdQSKnoXsACrDbRuKzDMVGfmRjR2S27+ua+8e61ttgqTC9CSJoZl8GI7wGTK2Xw9XBC/9VjSyeuCpBhXwOEx2qX/cs4b7RVRKSjBvYi8M21ma9tK25SXYVRs2c2nPl46CPCzDgR9SP4CG2iY5CEPzlya9pSL+86afOMQHSLTYydIh9uZwOzx56PxAD+oLgF4PEeSETXcgMKCHIOPiW1WU/qbdEuc04ojkWnxr8Mt1uOVaQvhknq93EL9RwTDYYJfwHzQY1MMVhS4L+G64YkBNH8uhURGmlr10vKXlKpiD5+OkLWhAgnWEDJr4+shB2EyDGDzLRQpsPGI/OEA5eEyyfAIdd4nMITnLR/4Gbe2WIGH970omvit/MJ4lqfFhH2bGe+jfEB+ywlNiE6HxDwsvHjZwowRhDt0cc5iXrsPBLhyYwVJByTlW3IzmdOk6CpuxULjGT2s/MPb5IfqZsyOZNv+61ohena9f4Uhzg2UhT92ZLW1LnhtevH/6y+vrJN2xTFCDdIjkgp6TykjhMwSRrwlj44/G+yJ3clfnTYYkq/TUkGC9KS3W6VkX/nsp6itgPOGVGAiqRZoI+WUjjAR/gpnKuIuNu80mOcU5j7bD5H5lXw6zO1uqRiQjr63WJoFjoG4gTkMNc7oPYRBEYAXdlRxuMArZ9wveQn/z6Mc07SXI3Vq9IV9OMLwQ4JgmX8J401UJ0IkG2i/MOqiVNRz3SUwPQ6KQwf/KlFN8h6i0DneFI117mkn6wvUbNVRKSnaG0qa2Sji8zfnR5flUYptE2Fdf+hqrLv0VZYAV9O7Umit5rVj9a2gVpZ8OrYxYZVC/5/i0wMAITL6KwvgzOgvUP+OUrvApT95oWK0qwPb4/kXw01WIwtXICUueQtfMuvp5UOp0oPLlcmdPiVNwp6geTkHgFIhsHYh0yGR/aKIRSo0NLiUYppb9lZSKUgrmm0vbWbrTVvkbhKkB0d9enc/na0j5z0kcQoZNY5DX8XckH/jgBzel7EBc9PCVn34GeRjvDD8OjAxEEfo7ieH/AeMc5nvDN7KDH0VGkhr75ACM9SmDsAxa1RgBRLRLkl0EHk6ga1b+CX/0I/DVx78Vf1Fh6n2eH5c3N/wh3hQG/Ko04K+Rl94azx6EzVYTpNXlHT3laHFiqVVicUQIyy7uxLQxu7hLh/WJIYswnOIf/G9o5RgeIQFN7rgrIcxau+xSW3PPnBGrrexHE4tIjuimqPMpolXXm+1hQJkUa9KPVy3VyPmozq0jVbRPwfb2Bzib2pCA3z7CLFjWdK7uk1NaQTO51JFokFQ/sjtRFgdr9IiQ1LYQxvD7pqSInI1Ffq9S80WWaykIA2VnXlMllQZfXOOxCP1VCxIGjqQu7yGci0Vfh99Y8dwAUQK6rJV9HH5jZPSUldGeNTOtVhlNSGaRaGgMh3Jo2tPOvbCoq2fUUhzEIoq4ZYodMTZhKEqlCLzExbWAiYsopBENEl8ljuFByQpRq0U+kkWTAT+FLaqAMbT3GhuHBTc3z3sMv0SJqf3jcWwcZ+bNZ90mLdszFd1W0aPKyBR3DK8uqvdJB26FlBJ3D6rdu2tVqTLFf+Eu9vNTyqfIqNxcWSXNQipKC+REDRVPERQ1VlK87E3nU132Oj24MjX6KABZfnvJPP7DJkqFxrrSxIYVeMkd4WodnFSKtxVDnf6lZ6jrYBZzrFL1aFaADoKE6xOK36zIm9V0H9ZqdKTjiAcPr86SturiiGFJxuoEXHk5T3e6UX3REOrVMfLZ6pN2Kfv/FW/aPBRvYs9wScV8abGH5HjqqQyKTzZJmvoRo59YcK2gdFzTgfVZGac3nuA+GCXnsErOtheeaxNaToeiBpUtVoRJGVJw4PppUZmtxhvciUyEbu5NvXkHLSxMCw+Ro5MWMUhqC5QgQfNn/TN/DZK76sSyRFjSsuYzT+OsCb2Zhpu9yFCrYKOtvPEO9iBDAddzGk6/RgJ8gYLGF1GgBo5Ggr+gHmTEgOWac1RHqJUGh/tS5q1PYcQz2XkN9NPi1b1RycXHRT9SFHHMhauTK2r/FP4CNijJsUuioEETcRP9VPml6uJX2IVRY6p+ldk39tS1zREo5KbgmIZxzqUNCRxRabjGu6IfhhAmJ2o4s217JBG69UOhr1vBxhOhz2APDAVsDis4c9ObjkOBLAY5SlqKqEDCR+SI10UvUrLDMq2FTkMCzTZOcnD0g+vySG1FhMvPIxgSBW6ZKU89+B9X85RPx9M6gq4+nNw2acy6AdE/8Y/G2wI/USLbLQ8905nqXvUqDRAleS4OehHg8WTB46ITGW6YzSxzoZkS2xSAKqA7CcAxYWs5+E30U+QZ7OeiMlE/MkRxp/OF9i2Shrt9dT8RQw8aqJ8S71APFSmkbG3L9izdiuLo536cQ1syO0VFRUulGr748JcGTTra6ifRW9whMkFRj/DPzHiBi29wgRXHS+eEomeOO7VnI6lXHG0SKtcaOp5qvUNdyFgZlu0ubO2CxY8i6BsgsxLE4JQijcJSg99mBJpE0VOioxdYvUlQZr5wF7oZBHyrHRJGAVMw/YR4+l+17m3xSni6Z+o4C61uCcrAX2++3dSapRrOxTkRNhlPHSu5apY7s2Y6iUKIiA2I2GgnBRuPDE9gDzI+GnRVLVMnBa7a+xN3ZZmoK9vDZ6ndpSMXXa62G9bpcXIWCmyywXgyGyv+18mZIT2nxtW25wvt7lCtn04b1vChgeOx33vUhYwKt73ZwtYdYSvn+dlPD8IoYw0cjQi/oR6kAkbuwprqjpOgaxn/dgIZMlKuT58pY68BG8O4KzuQmf5s6lnaI+1lOGxSRlJZH4CFj+AGFJ1UcVYZYixmnjOSResHX+AgTqlQLjQajCcb7qpuZMwW6BU5nnYNbU2SYx4ewm/FxZCku9MkTEvDEQhkTd4QvUlEnzuPTggLOFom1nr9Pldnu4YJdba5NNkLolv48VAdIamP2lP82GgwHj/WR1nkMkLWCOGKKvcHcpSXF6YGL+ARs4NFJ1J7E7rf2oMWdRKQVyxAA8cjw19C2UoBbzGf6SZCqZW2JxCBgKECAx2tYuIZ7kKKDObMm+q244LT4RCCbHcKA5Cz0QcWrJ8QH/bwu6If41fUkQwxFtO5N9ettML4S5iFaygW16xRSwP1E+JF1cOrx3cyNHBm5szVLSfzvZ9nh/s43OxZK4YGjsEMsAfj1b3xGvUhRQUbunj6qVBVCp2TNGLlAwc+zsaovv+EupGSElNvrt3TgdMtJeImSWNONojXYByCEIVmsWw9heNYuhkEneGr8htMiJIG6qcEvo2/23jl88fMHKligCkr4cBGsyd+ffPyF5mAtePazlglEwdo2SXHJAo5J3l5LUa0uOt+pIooZtPFQmuMskqKnsG6FAwsSTjwETKm754+NT6BdSU4pOgxm831kwO/5wGCyy1arIXBNhjDysC9iOsLeEkec6rf9IS+FhRcqJA6Cr9A37Ccdp3A4ASUuj8YI8JU9Wq8xN1KyF2e2IF62TV10/Ds7w9ihmKg+qnz6e75q4kSK808z/S66r77yl8/Pol92gt0zEgH6kMmLWTPp+58rMx6GGcoTSJMTxDwEQvXXhS9tGwUHl2mtjt3RmKQjTj0sxk57POEE/HhZSqcETRxHd3yo4M49FUC+RSQfEaOCnRBlHJli97CstpnPZ2YHn4TxFracolLZF9wdASdqhE3G06JZr2WyjaYtO8AdWocQbqF3QuVBQc+fP5vC6RiY4PHDPbcnC/aC+DVpr+FIyZWuTF1DkzDssO2Brn2UpUSpgudM93LTs6NTgJQMD3srjBjG/rl3rRdB6rN+LN/hhPa+2WRLkpskIvNBw+f928l3qp4l5fp4B6AWkxnHcEa9RWvHG6opUAsdMdrqJLCk7CAfsWYZQoTPHPecYpDffKHe7E5TMF0TfzVvUy9GO/Qn23PdS7+8Logc7F00Du0UqT+GzR0w/yeECIsyQVtdJH+zwX6hqiV8kJcqGQcnSqG2Fq1ESEMAjVbfIdCPZYm3GIpx5yJhfGFSWboIkSLvYiWR5Mo8FEEND0USXD6HhgWrJ8aL3+5I/ooeKVinH6uvOWZC7GeJgllzXg3RnLzkX6aRGHsC7cSr8EIWcmyF6XjJ9bUk6LHdOnA/y7kNtN60xkQErQZYUM9ftLvoKJltVXPk5RBkkaOU8opx+DrSShhauB4wuU16kLGk7Es1xbXYJI0gBvGk9M9+LwNMt3F2p7fRJfmwVIEm/nCjcIlxXwxd3UavGQAIzkcw6guNuLGOJpNRqyNvnQk5/qYltgSarCIs/TkBMgO1dhUS4/Ef3JgmUTUSBeb/IrwX8xD2IPxCnYhQ5Pp3LQX7fHi/iZKNQGhhUI2GNFAqb6VqmOeOmJyXHjEW3rO0mZfJuKGz4tLoi8SgrZPeA108canArdSbMRFx5BGchiz2M/Fl2ZcoKOxw3vchSEZM+Pdm7bwxDZ9g0MgbeSkyD5Zr+87DRFhK1288hx10C/hb9mLxdTSHVYqJzspbkAE8Y53246okeaQw+Q9gf93ia0GAByFhggNHOFGDdiDkvvrebOZ3E5xob6Vk6U130+S7UVeMrUx4mYj3jRivNkq2WmOYzVvYGwhkLc0lZIwAeaGA+/EBLeFrs1SvryFK4deg7MwMv099osfJPgCvWr9W1y8tpYjaKKyu74RvelUcl85ztLp3lenz9fr1IcuzBpOoUEbBqKLTR4jrOjGhZ1avmpmubO5tSCPSHPuxmSGfUOvSvN2TJbZqucnoQqXOL9YC5jsGAYg3VCnF/lgQT4A3U143bnLMKInyScleWPPLdsy20vc1XdZvgenzxIJ0JZ2Q0iBqjU//tYv++k4ZmuMrR9BCmue5x83IIJJFxeaZjdtiaBPFR6pU3nzmWe77RuGGRxxhqjaOYUYl9s5tolOEXEekW/XWAnvjCML5l98zL+nhHfZhNes6Zd765W9NJcYEfssWXXK6nd5wrP9XZL2y4TJWcXgXCVuO98pa8fU/oiZyrWuJZks4VMWRq8nKQQof4dXAs9aHgjUgaX7kS2ll60slNCRiLxW70t9jpMz5KIdyKAxSR2Cb2nTlA6Py4a/VQ3f44ZydQPedDZvF5wt42hKzqGPTpVojIFP+BVIylro/pfko3umfchPrzks71Nvn0lcle9NzJlhLZauJVtqhp4P3KWodoI9JULBmvzwEgJ/LYBy94pMZ2YHD3D6pF955L3P0EoGp3ubVLgBfv01TU4x97JNGt4kB6qdM57iFv1MKNtcLOwOc1wwEuFl9TzKWCaijDNbmtLmODSjwm+UFcaC+MbE86KBlH01c8xGgYWSPcEO6FIR1PqM+IfE8IPA8GOj2tX3yck4nLIc9Uq8JqD+QCpu9l2fppcgxiP8rvhtYZJImSIcbMVra1mBb5PfHtNkGyKztvOV8WdhFBnQhTG2IYiCzFgD9EpGnhhVS8M34NgMRKP/QE8lwj8MqAv4T4+rGDz0avS0KzTdY6/nGnuogLZymNTeL8ZCwptDZ03eZ4c0PO8TvsN+gTXFxEe4uJ/27M1lPB9zbi08zjMrtXiwZeQDOZSbR2Fwe2f9k7yCKN7m7JwclX3Nfm7L7uMwRsIyNQKQQ2rUm3kPYmMThZvPxnv0SAu6p+6ev3+5zGfhwjZXJnO82QP/CB3ufZKh+you0WoMKH9NwZcQnOGCfAk3IMNPwAdIeJGcOhRRk62foI/wMbbnxZeqtoDpTht3vHAWf+iI6+W/3EFHvYZVx/snuDgDA7MsTGJJSwOvI8pIdIcvAHqa8pJfICufWVCT1k8x/BIA9nN/7cfs9cs8kYKumeqwudjui5+ouI4KSTx76XbfC4NyLMckiVA86QtcwKbfxoU2CfOphBjobsi3sK2Ur2YvPIvz+KycEcYdVfnQ0z/wm1WcZefPROVVKD6G+lWoYcEbuTd55PW9ZVjmEp1R6t6qB7gF/CrBgxK5IcWaogbUc9m4Ve0r3RXtpG4GXszdRUccVjSGm80unKwhNxbfXB/ZUIKYPlAloepACa86gUvHPj9a/yqIWJ+Pk64gPYFCppoRDn/Bf2Sx4XTXWNEQsHtwc4T6QylW2cAhGaWsDIF3lemPCq7yfQgNCUgIeYsBBcWK67bkEgto2ML8Pw1ssi2CKpUAefa0+W6SYA3obrtixmI29dylK0cHaz6fC+lAA5t0QFAxHXinR1zT7q1XeOMpUwVFOLCPasm/5vrSBRBZ/4wBMzXqVVJuyFO0ERlk9WYs0PR/fjD/WgVhBwQ8v+aDIq9oDDix1x1T70Cj5b1AiKd8t7DjOcOBb/DBflqyIj3zNfwN0DMswt8APUMbENkmidXwyXBO63PpJVRyrvskBtSTjlIfbv2vVz0+Qwqxz3eohNyP7zlrLPW5jlcbEZulNBLZwR/Y9IqiXWstzfnSlCuKq+RmmEV+LKy2JsACS67weIyf1n5gIKn7c+fVCxij1LGvKXTQzPZLsvtUeE0Ofp6GX5mS6gZk6HSDySuMS+qiuOl0Pm2/B6zH8eow9uMNmFTpxknksxekixo1LaBnRSujSowad3FgvPTPxrsydymXFlvYjt0W1ey0i0Sj/ad0u1snVHrfjx5J20JCVC1uuHIqWUcmWefjxZIPLEtiwy8h63gHuXgGufsRZDG6D/6uwBhu07p4pUzBfwrjIDlf1x+uk+D+OoxjkCLUSqNmu7GVumlO6V/q8WVfT9ZqLYdG6QFmdNBsaUkeVi1PXYYb4YHMAqRHvUNkMlX+C2vutFSx91Ts8b3Qw6dgVAI/vlc6VOzC0VtOd5yD6vQGWt3tfq6CfyoWVTKlXoWxSYtNpeqbwt5Ex+3V7M3yeWvBre8EmFtkofJytTdz3Mapq9LeuItQ5g7JLNLgaK9wJMZF1+nwIlbKirVd7SgsibN0F7LnUMEXkN4HvnjX8BpQGSmqhdx9g1OnsS4C0vN6V01BFbLSlKNHtkmSY/U0SpMSTVCTBu8R7M+yD55YrjdrXvAhmH6zy5tqAyhTwF3ai6Ut9zgDCj5P3JCdPwmgiuPevPlt4r74IBcgXkwtTtmT0o4kh0JHDwfuRa7Jtg3TLP/RKP6BaChjhHAxyZofG5+R7fAnsEvSe5kYRF/7nAk+qZnkjKWjZjpvWkKcCvIPcru3tLtLefAVQGeQsamr+tcmn/8Z/Sz18LU7h//t3t91P9+jOgHSxYHaWu4Ki3wPinOxRSEdTSAW3KQUOl1TnHs18I2+UifoZ47tSKSO2L6pkmmV/JGLLn2xJF/USsEhBOnlEBJtwPAaNOnytmiheHDc9UyZvCave/pATrvx2UKluaxF4Uw9oTFBwZq0gUCVU2kLy5pyMmyEHpEPKlHjujkkwQn9jeo90Uhu0bnU1d1mk5zQK16/71Ed1HzVP/vWOdfiKO6qPoErGXxSouEfkyMqycVTHxKTyvBzo6qGs0pEAl08qz8XpS8RhblBR8BDxFY9Ax8NdLbmCAiSSTN8SlnpPohjmgjvpKpgXJfzLQTKnbA2p5wjgn28zWo8OGKQnOOBdi2bkqIO3LTustO6Mj5XvVJrKG6ozb2doVsNJC9IIa929ONA9BikuBmVBFG9yXEOdZQpcYhWPIBKga+qEq5BbLD1/Q1vCfu7ORgjV/4o+TsYzaDUQoFhUEwMo1hHp5T1Y+jziyrcOlc80ZztEyg9henYGsqPjj1HYKnaV3QxokQQgukXiaQoxAXX1352fARlw61m0SRf2kI4qPRZ3MvCK62XN1tacqGSKs+2D3f7CL9YQHsE3Bb8k6bG86qNzOKhBzssicXjDgDfkDBpOgRDAtFf83LrGkbPzYtQ7IEfQJYaXKG0Gn5MFSJZ36NgbwdjyiDCQrVL5sqNCbOkEJOkwEaICnnNrJaSxEZ4tJZA1c3RAkKyHPRgxYZoU0ooV+asypv2VqLKHgUBM8e3RIoiDv8H/FOXyg==
In all likelihood they created this string in such a way that you couldn't change it.
This isn't that they haven't thought about whether or not they want the data to be changed, they have specifically sought to obfuscate it to make it harder to change, which suggests they don't want you to do it.
Given that you are using some else's code, you should carefully check what license covers your use of the code and whether it permits you to make the modification. Once you've done that, you should approach the originator of the code to ask them how to make the change, if you feel you are entitled to.
My guess is that you have a script that contains this string. Check if you have eval() function calling this string to be base64_decode (ed). Change the eval to print. Then, execute it, redirecting the output to a file for later reading.
kevin#server:~# php suspicious_script.php > out.php
You should be able to see what's going on.
I am writing a PHP application that will have the ability to edit settings through a web interface. I didn't mean for the user (and actually, it will only be admins) to be able to load the file up in a text editor, but rather, they make a change using a form, and that will change the settings file (and do other things as well).
At this stage in the development, settings are stored in a PHP file, for example:
define ('UPLOAD_DIR','uploads/');
define ('DISPLAY_NUM',true);
$names = array('a' => 'b','c'=>'d','e'=>'f');
However, parsing arrays (and they get more complicated (i.e multilevel nested) than the above), doesn't seem so fun. And because specific settings can be added and removed, reading the entire file, and then writing out all the settings again, doesn't seem fun either.
What are the advantages and disadvantages to using the following formats? (And any others that I missed out):
Custom XML
INI (able to use parse_ini_file)
(Using a database is not suitable due to the requirements for the project. I understand in many situations a database would be prefered, just not in this case.)
If you were unable to use a database, and had to store settings that could be edited using a web interface, what would you do?
(Note: This is a different question to this one, where settings can't be changed, it's PHP file all the way. And yes, the setup does currently write out a PHP file with the correct settings.)
If you're not committed to using XML, you may like to consider YAML. I've only used it with Ruby, but a quick Google suggests there are a few options for PHP support. TBF, the links there include some arguments against using YAML with PHP, but YMMV.
OK, I didn't get any sort of answer I was looking for. Here's the sort of thing I was expecting.
INI
Storing settings in an INI file might be appropriate for simple settings which you want the user to edit by hand.
However, creating complex arrays is not easy, and would require some mental acrobatics to understand which heading is at which level of the array.
Reserved words, which must not be used anywhere in the file, include: yes, no, true, and false, this might be problematic.
Constants can be used in the file.
No built in method of writing out INI files.
XML
Can use the SimpleXML Extension, which "provides a very simple and easily usable toolset" to turn XML into an object that can then be processed using the normal methods.
Allows the use of very complex arrays.
Possible to edit by hand, if required.
Can use external tools to verify the validity of the file.
Many many XML processors available for PHP.
YAML
http://yaml.org/
http://www.techyouruniverse.com/software/dont-use-yaml-for-php-use-parse%5Fini%5Ffile
Remember: no database. Requires being able to use complex arrays.
I wouldn't like the idea of someone having direct access over settings, so it's important to provide an interface to act as a buffer, preventing deliberate attacks and ensuring clean output.
With that in mind the choice of server side format is not important at all, as long as you can interface with it correctly all other problems can be worked around.
I'd recommend a custom XML file, that way your config will scale well and you can use PHP XML libraries to access it.
A quick example:
<myconfig>
<define>
<name>UPLOAD_DIR</name>
<value>uploads/</value>
</define>
<define>
<name>DISPLAY_NUM</name>
<value>true</value>
</define>
<array id="names">
<value index="a">b</value>
<value index="c">d</value>
<value index="e">f</value>
</array>
</myconfig>
PHP has built in functions for editing and parsing INI files, which use a plain-text format to store program settings.
http://us.php.net/manual/en/function.parse-ini-file.php
http://us.php.net/manual/en/function.parse-ini-string.php
I have used a two step approach. The variables and their names are stored in the database with an interface that gives the user the ability to change them. When they change them a file gets saved onto the server and then referenced throught out the application (The changes are alos saved back to the DB). Makes updating easy and makes backups simple - no need to backup the files, just backup the database. The resulting files are just .inc files that are in the format $variableName = 'variablevalue';
And why not plain php?
configure-form.php
form method=POST action='configure.php',
input fields ex. name='upload' value='<?php echo UPLOAD; ?>'
a configure.php file:
$myfile = 'sets.php';
$fh = fopen( $myfile, 'w' );
$upload = '"/upload/"';
$txt = "define( UPLOAD, '" . $_POST['upload'] . "' );";
fwrite( $fh, $txt );
fclose( $fh );
and there you have it. Simple php which creates configure file for you.