Re: [PHP] Cookies & sessions
On Sun, 24 Jan 2010 17:44:16 +1100, clanc...@cybec.com.au wrote: >On Sat, 23 Jan 2010 15:10:11 +, nrix...@gmail.com (Nathan Rixham) wrote: > > >> >>To answer your specific questions though - what can be done to make this >>process more secure - no matter what approach you take, when working via >>http and needing logged in / secure functionality; you need the client >>to identify themselves with a key of some sort - no matter how you make >>the key it's always going to be passed via http (GET/POST/COOKIE) - if >>some "hacker" passes the same key then your system is going to think >>it's the original user and give them access. >> >>To make it trickier you can store information such as the users IP >>address, user agent string etc in session and compare it on each >>request; if it changes log the user out and destroy the session data - >>however your never going to protect against the most common form of >>"hacking", a nosy co-worker / person in the same house having a nosey >>while the user is at the toilet / making a brew. This is why many sites >>re-request password confirmation for potentially sensitive actions like >>transferring money, changing personal details and so forth (and send >>email confirmations to tell the user what changed - just in case). >> >>It must be pointed out though that non of this is worth even considering >>if you have sensitive ports (like ftp/ssh/mysql) open to the outside >>world as it's these back doors people will use to hack the whole server, >>not just one users personal account on a single site. Also protect >>against SQL injection attacks by sanitizing your data and so forth. > >Thank you for your thoughtful suggestions. I totally agree. If someone goes >sniffing, or >the like, they might be able to get somewhat limited access to the domain. On >the other >hand if they can crack the FTP, and get into the master server, they can >download the >whole site. > >>Finally, view it as your responsibility to never store anything personal >>or identifying (or in fact anything) on the client side in a cookie - >>one simple key (session_id) in the cookie and everything on the safe >>secure server is the way to go. > >I have thought of storing customising information for a particular user in a >cookie, but >it would simply consist of a set of parameter values. As they would be >processed in >exactly the same way as if they had been entered as parameters they would >presumably >represent no more, or less, threat than the parameters which are essential to >the >operation of the site (and which can readily be read, or bookmarked -- or, on >reflection, >experimented with). Well! My reflection above cast a completely different light on the situation. It turns out that from a security point of view the multiple domains of Quadra Hosting's scheme should all be regarded as a single domain. In this system each domain has a separate directory under the site root directory. I suspect that any browser access to any of the domains is treated as user group 'other' (with the site owner being owner). This means that any program operating in any domain can read any file in any of the other domains, or in any other directory in the site. This is a bad enough security hole, but in my system I have a separate directory 'Engine' containing the logic to display any of the pages in any of the domains. Each domain has a separate copy of index.php, which sets up a few variables, and then invokes the engine. The individual pages are displayed by a call to index.php, followed by a series of parameters. I have one 'secure' site which is password protected, and engine won't do anything until the user has logged in. However the parameter system can handle indirect paths, and I discovered this morning that if I opened a page on one of the other domains, and then passed the appropriate parameters, I could get into the secure domain, and navigate normally through it. Images are not displayed, as the path is not calculated correctly, but everything else is, and you can read the image properties, and from this work out their correct path. Even worse, if you know their addresses, you can download any of the images or data files simply by typing the address into a browser. I could prevent the cross coupling trick by blocking any path referring to the secure directory, and I could put the data files in a separate directory off to the side, so that they could not be directly downloaded, but as the browser has to be able to download the images (and any documents or spreadsheets) directly I cannot see any easy way to protect them. So much for worrying about the relative virtues of cookies and sessions! Clancy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Php-cli, scripts freeze on exit
On Mon, Jan 25, 2010 at 1:16 AM, David W. Allor wrote: > Hi! > > I'm using php-cli 5.3.1. > > When I run php from the command line, the script does not return me to > the command prompt when exited. The script always completes, but it has > to be killed to release it's resources. > > I've created a little working example: > > > #!/usr/bin/php > echo 'hellu'; > exit(0); > ?> What if you dont use any exit(0) ?? -- Shiplu Mokaddim My talks, http://talk.cmyweb.net Follow me, http://twitter.com/shiplu SUST Programmers, http://groups.google.com/group/p2psust Innovation distinguishes bet ... ... (ask Steve Jobs the rest) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Php-cli, scripts freeze on exit
Hi! I'm using php-cli 5.3.1. When I run php from the command line, the script does not return me to the command prompt when exited. The script always completes, but it has to be killed to release it's resources. I've created a little working example: #!/usr/bin/php I execute the script by running "./test.php" The script outputs "hellu" and then stops. It does not return to the command prompt. The only way back is to kill the script. This problem does not occur on my remote server, only on my home environment. I have home-network maintenance scripts that execute other scripts. If the executed script doesn't exit, the main scripts don't continue. I did a trace, and it turns out that the script is stopping on a futex wait. Thanks, David W. Allor
Re: [PHP] memory efficient hash table extension? like lchash ...
shiplu wrote: On Sun, Jan 24, 2010 at 3:11 AM, D. Dante Lorenso wrote: All, I'm loading millions of records into a backend PHP cli script that I need to build a hash index from to optimize key lookups for data that I'm importing into a MySQL database. The problem is that storing this data in a PHP array is not very memory efficient and my millions of records are consuming about 4-6 GB of ram. What are you storing? An array of row objects?? In that case storing only the row id is will reduce the memory. I am querying a MySQL database which contains 40 million records and mapping string columns to numeric ids. You might consider it normalizing the data. Then, I am importing a new 40 million records and comparing the new values to the old values. Where the value matches, I update records, but where they do not match, I insert new records, and finally I go back and delete old records. So, the net result is that I have a database with 40 million records that I need to "sync" on a daily basis. If you are loading full row objects, it will take a lot of memory. But if you just load the row id values, it will significantly decrease the memory amount. For what I am trying to do, I just need to map a string value (32 bytes) to a bigint value (8 bytes) in a fast-lookup hash. Besides, You can load row ids in a chunk by chunk basis. if you have 10 millions of rows to process. load 1 rows as a chunk. process them then load the next chunk. This will significantly reduce memory usage. When importing the fresh 40 million records, I need to compare each record with 4 different indexes that will map the record to existing other records, or into a "group_id" that the record also belongs to. My current solution uses a trigger in MySQL that will do the lookups inside MySQL, but this is extremely slow. Pre-loading the mysql indexes into PHP ram and processing that was is thousands of times faster. I just need an efficient way to hold my hash tables in PHP ram. PHP arrays are very fast, but like my original post says, they consume way too much ram. A good algorithm can solve your problem anytime. ;-) It takes about 5-10 minutes to build my hash indexes in PHP ram currently which makes up for the 10,000 x speedup on key lookups that I get later on. I just want to not use the whole 6 GB of ram to do this. I need an efficient hashing API that supports something like: $value = (int) fasthash_get((string) $key); $exists = (bool) fasthash_exists((string) $key); fasthash_set((string) $key, (int) $value); Or ... it feels like a "memcached" api but where the data is stored locally instead of accessed via a network. So this is how my search led me to what appears to be a dead "lchash" extension. -- Dante -- D. Dante Lorenso da...@lorenso.com 972-333-4139 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Users, groups, and permissions
clanc...@cybec.com.au wrote: > I am using a Quadra Hosting Multi Domain (http://www.quadrahosting.com.au/) > to host five > different domains. As site owner I have FTP access to the root directory, and > to > everything underneath it. There is no domain directly attached to the root. > Each domain > has its own directory tree under the root directory, and I have a separate > directory > Engine containing the PHP code for all the sites. Each domain directory has a > series of > data files defining the various pages, optionally some configuration files, > and a very > short program index.php, which sets up a few user variables, and then passes > control to > the main program in Engine (by including it). The Engine processes a set of > parameters, > and from these generates the actual page which is passed to the user. The > data files are > almost entirely simple text files, and I do not use a database. > > The permissions are currently as they were set up by the provider. All > directories in the > system have permissions drwxr-xr-x, and all other files rw-r--r-- (when I > read them as > site owner -- I don't know if they are somehow changed when I access the site > by > downloading a page from one of the domains). I can load and run any of the > files in Engine > by including them into Index.php, and I can include images anywhere in the > domain in the > current page. I can also download them directly by quoting their full path. I > can also > show pages defined by data files in Engine, but I can neither show nor > download images in > Engine. I haven't tried accessing pages in other domains. > > As the permissions for group and others are the same for all directories, and > all files, I > don't understand how I can download images in the current domain, but not in > Engine. Is it > possible to reset the permissions so that different values are seen from > different > domains, and how can I tell which group I am actually in when I access a > particular > domain? Also is it possible to temporarily include a user in group, if they > are not > already there? > > Clancy. > > (The PHP manual has been down all day, and Google is not particularly helpful > for this > type of thing unless you already know the terminology, so I have largely been > floundering > in the dark. And when you look up 'user permissions' most books immediately > assume > database.) > Hi Clancy, If I read what you are saying correctly you have the following directory tree /SiteA/ <-- domain files /SiteB/ <-- domain files /SiteC/ <-- domain files /Engine <-- private files if this is correct then: www.somesite.com is mapped to /SiteA/ so if you have the file /SiteA/test.jpg you can access it via www.somesite.com/test.jpg if I'm still correct.. then the problem is that /Engine/ *is not* mapped to any domain - thus you can't access it via http. Any request to www.somesite.com/Engine/test.jpg will map to /SiteA/Engine/test.jpg and not /Engine/test.jpg as you'd want. If I'm wrong the you need to explain some more :) Regards, Nathan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Cookies & sessions
clanc...@cybec.com.au wrote: On Sat, 23 Jan 2010 09:32:37 -0500, tedd.sperl...@gmail.com (tedd) wrote: At 1:13 PM +1100 1/23/10, clanc...@cybec.com.au wrote: but I would be grateful for any suggestions how I could make this procedure more secure. We have given you advice that you should NOT use Cookies in any fashion to secure your site, but you remain steadfast that you know better -- so, what else can we say other than good luck. BUT you have told me to use sessions, and sessions use a Cookie! If the Cookie I use contains random data, the only difference in security is in the time that it remains valid. Neither contains any useful information, but while they are valid both will enable you to bypass security. Using only sessions means you have the tried and true php session handling to manage the cookie, rather than re-inventing the wheel yourself by using your own random string to do the same thing that a session cookie already does. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
