php-general Digest 3 Dec 2011 16:46:07 -0000 Issue 7596
php-general Digest 3 Dec 2011 16:46:07 - Issue 7596
Topics (messages 315920 through 315923):
Re: file_exists fun
315920 by: Dee Ayy
DOS CLI?
315921 by: Matt Neimeyer
315922 by: Shawn McKenzie
Re: Common way to store db-password of open session?
315923 by: Andreas
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
--
---BeginMessage---
On Fri, Dec 2, 2011 at 1:30 PM, Dee Ayy dee@gmail.com wrote:
The following code:
$new_file =
ADS_DIR_INTERNAL.'/'.$ad_info['id'].'_'.$ad_info['filename'];
echo NEW_FILE:[.$new_file.]\n;
echo file_exists Using
VAR:[.file_exists($new_file).]\n;
echo file_exists Using Hard
Coded:[.file_exists('/home/fx/pads/ads_dir/1_rubik1920x1080lu0.jpg').]\n;
Gives this output:
NEW_FILE:[/home/fx/pads/ads_dir/1_rubik1920x1080lu0.jpg]
file_exists Using VAR:[]
file_exists Using Hard Coded:[1]
Why does it not work when using the variable in file_exists?
I thought I may need some safe_mode magic, safe_mode_include_dir, or
disable_functions, but I don't see any restrictions AND why does it
work when it is hard coded?
Warning
This function returns FALSE for files inaccessible due to safe mode
restrictions. However these files still can be included if they are
located in safe_mode_include_dir.
Current logic needs the following functions:
file_exists
md5_file
move_uploaded_file
Thanks.
From PHP, exec('whoami') says www-data, so I created /home/www-data
and chown to www-data.
file_exists with a variable still fails.
Initial and future testing of !file_exists(ADS_DIR_INTERNAL) works to
create the directory only once as intended, however ONLY initial
creation of the file inside the directory works with
move_uploaded_file.
Attempting to overwrite an existing file with move_uploaded_file fails.
I then tried exec('mv '.$_FILES['my_file']['tmp_name'].' '.$new_file)
as well as mv -f
which DOES COPY the filename of tmp_name to the correct directory
ADS_DIR_INTERNAL, but keeps the tmp_name filename! It is not renamed
as a true linux mv.
I assume it is some protection due to being an uploaded file.
---End Message---
---BeginMessage---
Is there (or is there a way to compile) a DOS CLI version of a fairly
recent version of PHP? I have not been able to find one using the
powers of Google.
Not a Windows Command Prompt CLI but an actual CLI version of PHP that
can be made to run in a real DOS environment?
I'm sure I could find another scripting language for DOS but to
prototype this project I'd like to not have to learn a new language as
well. :)
Thanks in advance for ANY suggestions.
Matt
---End Message---
---BeginMessage---
On 12/02/2011 03:00 PM, Matt Neimeyer wrote:
Is there (or is there a way to compile) a DOS CLI version of a fairly
recent version of PHP? I have not been able to find one using the
powers of Google.
Not a Windows Command Prompt CLI but an actual CLI version of PHP that
can be made to run in a real DOS environment?
I'm sure I could find another scripting language for DOS but to
prototype this project I'd like to not have to learn a new language as
well. :)
Thanks in advance for ANY suggestions.
Matt
Uh No. There's not one for the original Berkeley or ATT UNIX,
VMS, CPM, Commodore 64, Mac OS 9 or Amiga either as far as I know. The
DOS that ran on TRS80, concurrent DOS and Zenith DOS are right as well.
I'm sure that if you submit a feature request they would be all over it.
--
Thanks!
-Shawn
http://www.spidean.com
---End Message---
---BeginMessage---
Am 29.11.2011 23:54, schrieb Tamara Temple:
As I read it, the OP may be confusing application user logins and the
credentials used by the application to access the data base.
Individual application users should *NOT* have access directly to the
data base by having their individual credentials in the db access
list. The application should have a unique set of credentials for
accessing the database, and the only way users can gain access to the
database should be through the application. Do NOT store data base
credentials anywhere in the session or in cookies, either, as that can
give people access to your database as well.
Actually the OP is trying to figure out, why it is a good thing to have
just one set of db credentials for the application instead of individual
credentials for every user.
The DBMS has a fine grained permission control system in place.
The issue about thuis is I need to keep the users dbuser and password in
a session or cookie because I need it for every connection to the DB.
On the other hand a common way seems to be to check the
Re: [PHP] Common way to store db-password of open session?
Am 29.11.2011 23:54, schrieb Tamara Temple: As I read it, the OP may be confusing application user logins and the credentials used by the application to access the data base. Individual application users should *NOT* have access directly to the data base by having their individual credentials in the db access list. The application should have a unique set of credentials for accessing the database, and the only way users can gain access to the database should be through the application. Do NOT store data base credentials anywhere in the session or in cookies, either, as that can give people access to your database as well. Actually the OP is trying to figure out, why it is a good thing to have just one set of db credentials for the application instead of individual credentials for every user. The DBMS has a fine grained permission control system in place. The issue about thuis is I need to keep the users dbuser and password in a session or cookie because I need it for every connection to the DB. On the other hand a common way seems to be to check the users credentials and store just some kind of LoggedIn = TRUE and use the credentials of the application for queries. But this way I had to reinvent the access control system within the application. I'm rather leaning to the 1'st way with individual credentials because I haven't seen convincing arguments against it, yet. Right now we are talking about a web server that has just a very limited set of local users that might get the idea to snoop in /tmp for session files. AFAIK according to default settings the garbage collection runs not very ofthen on low frequented sites so stale session files could stay in /tmp for months. That is not very comfortable, though. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] End of session clean-up
Hello all. I need to purge old records from application tables when a session expires. How do I register a callback with the end-of session-garbage collection system ? session_set_save_handler() lets me override the native garbage collection, not *add* to it, as far as I can tell. Thanks in advance. -- André Majorel http://www.teaser.fr/~amajorel/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Common way to store db-password of open session?
On 3 Dec 2011, at 16:46, Andreas wrote: Am 29.11.2011 23:54, schrieb Tamara Temple: As I read it, the OP may be confusing application user logins and the credentials used by the application to access the data base. Individual application users should *NOT* have access directly to the data base by having their individual credentials in the db access list. The application should have a unique set of credentials for accessing the database, and the only way users can gain access to the database should be through the application. Do NOT store data base credentials anywhere in the session or in cookies, either, as that can give people access to your database as well. Actually the OP is trying to figure out, why it is a good thing to have just one set of db credentials for the application instead of individual credentials for every user. The DBMS has a fine grained permission control system in place. The issue about thuis is I need to keep the users dbuser and password in a session or cookie because I need it for every connection to the DB. On the other hand a common way seems to be to check the users credentials and store just some kind of LoggedIn = TRUE and use the credentials of the application for queries. But this way I had to reinvent the access control system within the application. It's highly unlikely that the access controls needed for any given application match those that can be implemented with DB users without either a) making the DB schema so complicated that it becomes unmaintainable, or b) making the permissions so complicated that it becomes unmaintainable. I'm rather leaning to the 1'st way with individual credentials because I haven't seen convincing arguments against it, yet. Think about it in terms of roles. As far as the database is concerned, access roles are fairly course such as user or admin. Application roles are likely to be more refined, such as visitor, subscriber, premium member, etc. It's quite likely that the DB roles will require selective access to tables (e.g. admin can write to everything but user can mainly only read), whereas user roles will require selective access to rows (e.g. restricted access to premium content). The other thing to bear in mind is that maintaining such a permission set with database users is far more involved than maintaining it within the application logic, and usually far less flexible. Right now we are talking about a web server that has just a very limited set of local users that might get the idea to snoop in /tmp for session files. AFAIK according to default settings the garbage collection runs not very ofthen on low frequented sites so stale session files could stay in /tmp for months. That is not very comfortable, though. If you have untrusted local users then you should not be storing any sensitive data on that machine. Period. Or any other machine to which that machine connects. It also worth noting that even if you did go down this route you don't need to store the DB credentials in the session. You must have retrieved them from somewhere when the user logged in, so simply store a user identifier in the session and use that to retrieve the DB access details. You appear to be wanting to overcomplicate your application for no good reason that I can see. Beyond the fact that you think it's duplicating functionality (which it's not really), why would you want to do this? -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] End of session clean-up
On 3 Dec 2011, at 16:57, Andre Majorel wrote: Hello all. I need to purge old records from application tables when a session expires. How do I register a callback with the end-of session-garbage collection system ? session_set_save_handler() lets me override the native garbage collection, not *add* to it, as far as I can tell. You would need to implement a complete session handler to add your own functionality into the GC. However, the fact that you want to do this begs the question, why are you storing what sounds like session data in application tables instead of storing them in the session? -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] End of session clean-up
On 2011-12-03 17:41 +, Stuart Dallas wrote: On 3 Dec 2011, at 16:57, Andre Majorel wrote: Hello all. I need to purge old records from application tables when a session expires. How do I register a callback with the end-of session-garbage collection system ? session_set_save_handler() lets me override the native garbage collection, not *add* to it, as far as I can tell. You would need to implement a complete session handler to add your own functionality into the GC. Rats. However, the fact that you want to do this begs the question, why are you storing what sounds like session data in application tables instead of storing them in the session? This session data is similar to a purchase basket. It references tuples from the static tables. If it's outside of the database, we lose the benefits of a relational DBMS. -- André Majorel http://www.teaser.fr/~amajorel/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] End of session clean-up
-Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ On 3 Dec 2011, at 18:07, Andre Majorel wrote: On 2011-12-03 17:41 +, Stuart Dallas wrote: On 3 Dec 2011, at 16:57, Andre Majorel wrote: Hello all. I need to purge old records from application tables when a session expires. How do I register a callback with the end-of session-garbage collection system ? session_set_save_handler() lets me override the native garbage collection, not *add* to it, as far as I can tell. You would need to implement a complete session handler to add your own functionality into the GC. Rats. However, the fact that you want to do this begs the question, why are you storing what sounds like session data in application tables instead of storing them in the session? This session data is similar to a purchase basket. It references tuples from the static tables. If it's outside of the database, we lose the benefits of a relational DBMS. Writing a session handler is pretty straightforward. I wrote about how to implement one to use MySQL a while back which I'm sure you could easily adapt to your needs. http://stut.net/2008/07/20/mysql-sessions/ -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Common way to store db-password of open session?
Andreas maps...@gmx.net wrote: Am 29.11.2011 23:54, schrieb Tamara Temple: As I read it, the OP may be confusing application user logins and the credentials used by the application to access the data base. Individual application users should *NOT* have access directly to the data base by having their individual credentials in the db access list. The application should have a unique set of credentials for accessing the database, and the only way users can gain access to the database should be through the application. Do NOT store data base credentials anywhere in the session or in cookies, either, as that can give people access to your database as well. Actually the OP is trying to figure out, why it is a good thing to have just one set of db credentials for the application instead of individual credentials for every user. The DBMS has a fine grained permission control system in place. The issue about thuis is I need to keep the users dbuser and password in a session or cookie because I need it for every connection to the DB. If you give every application user a unique set of database access permissions, that means that any one of those users can access your data base WITHOUT going through your application if they manage to get access to your data base server. Is that clearer? Your application's users should not be able to access the data base directly. The application should be the thing to manage the data base. You may want to have different data base credentials for different user *roles* (plain, privileged, admin roles, etc), but to give *every* application individual data base unique credentials is not only unnecessary, but also a security risk. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
