php-general Digest 3 Dec 2011 16:46:07 -0000 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
----------------------------------------------------------------------
--- Begin Message ---
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 ---
--- Begin Message ---
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 ---
--- Begin Message ---
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
Uhhhhh.... No. There's not one for the original Berkeley or AT&T 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 ---
--- Begin Message ---
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.
--- End Message ---
