php-general Digest 12 Jul 2006 13:18:01 -0000 Issue 4235
Topics (messages 239332 through 239338):
List of Restricted Countries to Leave Out of Credit Card Form?
239332 by: Michael B Allen
Re: How do I prevent a session from rebuilding itself?
239333 by: Robert Cummings
239335 by: Daevid Vincent
239336 by: John Wells
Re: DB Create Table help - using Pear DB
239334 by: Scott Heinrichs
array_search and in_array
239337 by: João Cândido de Souza Neto
Re: GD to database directly
239338 by: Jay Blanchard
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
For my credit card form I provide the user with a list of countries. I
suppose these are ISO country codes? For the US is there an official
list of countries with which I'm not supposed to do business with? Will
Authorize.Net catch those transactions?
Thanks,
Mike
--
Michael B Allen
PHP Extension for SSO w/ Windows Group Authorization
http://www.ioplex.com/
--- End Message ---
--- Begin Message ---
On Tue, 2006-07-11 at 17:27, Daevid Vincent wrote:
> I've noticed a 'feature' that seems to be causing me some pain.
>
> When a user logs in, we store various pieces of info and their user class in
> a $_SESSION variables.
>
> This includes a flag saying that they've ben authenticated.
>
> I would expect that if I 'rm -rf /tmp/sess_*' that the user would get
> prompted to re-login (since the flag is not set).
Does it say someplace in the manual that you should be able to do that?
Or is this a case of what you expect is not what the rest of the world
expects? Ok, that's maybe not fair, but "rm -rf /tmp/sess_*" is
completely prone to race conditions.
> However what actually happens, is that PHP silently just re-creates the
> session with a new unique identifier but with all the same data in it. GRRR.
Are you sure that PHP is the one completely recreating the session? Do
you have some kind of "remember me" facility using a permanent cookie
that enables your scripts to recreate a session with a new identifier?
Because PHP doesn't usually do that by itself.
> How can I force this to NOT happen (either via php.ini or via some function
> or directive call in each page load)?
Try this...
/etc/init.d/apache stop
rm -rf /tmp/sess_*
/etc/init.d/apache start
If that doesn't prevent recreation of the session then see the "remember
me" comment above (you may need to replace the above shutdown/startup
commands with whatever works for your OS/distro.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--- End Message ---
--- Begin Message ---
> The session data that you store in $_SESSION is written to
> the files in your /tmp dir.
> Are you sure your session files are getting written to that directory?
Yes.
> You are sure those aren't old session files from a previous configuration?
Positive. I wipe the /tmp dir clean. Login to my page (user/pw,
authentication, etc). See the sess_ file created. Delete the file. Reload
the page, and a new sess_ file is created (with a new session ID hash). I
would expect my session to be invalid and force me to login again as I do
this kind of thing at the top of every page in the header:
if ( !is_bool($_SESSION['login']) || $_SESSION['login'] != true )
{
exit("<SCRIPT>location.href='/index.php';</SCRIPT>");
}
> Are you working with a project/site on that box that uses
> custom session handlers?
No.
> Perhaps some of your sites write to that dir, but
> the session in question are getting written to your database.
No.
> If everything you've said is 100% accurate, then I would check for
> Gremlins. The session data only exists in memory or in those session
> files in the /tmp dir.
Yes.
> The symptoms you see could be caused by:
> 1. Starting a session
> 2. Saving data into the $_SESSION super global.
> 3. rm'ing all of the session files.
> 4. Closing your current session.
> --> all done in the same page.
We do write to $_SESSION all the time. For example at the top of each page
we update the timestamp so we know if we should auto logout the user after
10 minutes...
> I am thinking you are killing the first session, rming the
> files, then
> creating a new session. At the end of the page the data that was in
> memory is getting written to the new session file.
Yes. That's what is happening as I said. I don't want it to re-write.
Ironically we used to have this problem with our PHP bug tracking system,
where every few hours or whatever, people would get logged off. Turned out
that some cron was purging all of /tmp. I fear that this 'bug' was 'fixed'
in PHP 5 or something and so in a 'helpful' way, PHP restores the session
from memory. I do NOT want that to happen.
> Regards,
> Mrs. O'Toole
>
> Daevid Vincent wrote:
> > I've noticed a 'feature' that seems to be causing me some pain.
> >
> > When a user logs in, we store various pieces of info and
> their user class in
> > a $_SESSION variables.
> >
> > This includes a flag saying that they've ben authenticated.
> >
> > I would expect that if I 'rm -rf /tmp/sess_*' that the user
> would get
> > prompted to re-login (since the flag is not set).
> >
> > However what actually happens, is that PHP silently just
> re-creates the
> > session with a new unique identifier but with all the same
> data in it. GRRR.
> >
> > How can I force this to NOT happen (either via php.ini or
> via some function
> > or directive call in each page load)?
> >
> > ÐÆ5ÏÐ
>
>
--- End Message ---
--- Begin Message ---
On 7/12/06, Daevid Vincent <[EMAIL PROTECTED]> wrote:
> I am thinking you are killing the first session, rming the
> files, then
> creating a new session. At the end of the page the data that was in
> memory is getting written to the new session file.
Yes. That's what is happening as I said. I don't want it to re-write.
Just to be clear, what exactly are you trying to do? Are you trying
to kill a session, as in log a person off? Then do so within PHP:
[code]
// set $_SESSION to empty array
$_SESSION = array();
// if saving session in cookie, clear that out too
if(isset($_COOKIE[session_name()]))
{
setcookie(session_name(),'',time() - 4800,'/');
}
// destroy session completely
session_destroy();
[/code]
HTH,
John W
--- End Message ---
--- Begin Message ---
Jochem Maas wrote:
Scott Heinrichs wrote:
Hello all,
This is the first time I have posted an issue to this forum, so please
excuse in noob questions or statement. I am trying to create a table
from a string that created by a DESCRIBE TABLE query... this is the
generated string:
CREATE TABLE 'users' ( 'username' varchar(120) NOT NULL primary key,
'password' varchar(64) NOT NULL, 'level' int(11) NOT NULL DEFAULT '0'
)
then I use the statement:
$db is a PEAR DB object that has been set up with my database access
info and connects to MYSQL.
$stmt = above create string.
$db->query ( $stmt );
for some reason it is not creating the desired table.
Im sure the $db object has some error related methods that will give some
information
as to the problem.
some ideas:
1. your using transaction and not commiting after the query
2. the user you connect as doesn't have 'create table' permissions
3. $stmt doesn't contain what you think it does.
4. the SQL is invalid (doesn't look like it though.)
no.2 seems most likely.
Can anyone give
me a solution or a reason why the above situation would not work. Just
to clarify that my Database info is correct I was able to generate the
create string from a DESCRIBE TABLE query so the connection works and
is valid and I have CREATE rights.
Ok... I can log in to the mysql padmin and create a table using the same
connection info. I am assuming this would mean that I should have create
rights when I connect through my script. I am not 100% on this and I am
unable to find out what my GRANT rights are at least not in a timely
fashion. My script currently checks for errors and it is not generating
any....
$result = $this->db->query( $stmt );
unset( $stmt );
if ( PEAR::isError($result) )
{
$this->hasError = true;
$this->errorCount++;
array_push ( $this->errorMessage, "Error: Unable to create
Table in Database" );
return false;
}
This is a snippet from my code.... It should catch the error. When I run
the script no error is generated. Is there a better or more reliable way
to write SQL syntax for creating a table then the one I am using... here
it is again:
CREATE TABLE 'users' ( 'username' varchar(120) NOT NULL primary key,
'password' varchar(64) NOT NULL, 'level' int(11) NOT NULL DEFAULT '0'
)
The above line was captured from an ECHO of the $stmt variable so I know the
$stmt is what I expect it to be.
I know that I am not using transactions.
--- End Message ---
--- Begin Message ---
Hi everyone.
I´m facing a big trouble that a don understand why is it happenin.
I´ve got an array with 1046 elements in it like this.
Here is a part of a print_r of my array.
Array ( [0] => 0001-01 [1] => 0003-01 [2] => 0140-01 [3] => 0141-01 [4] =>
0142-01 [5] => 0170-03 [6] => 0181-01 [7] => 0182-04 [8] => 0186-06 [9] =>
0186-08 [10] => 0550-01 [11] => 0720-01 [12] => 0730-01 [13] => 0740-01 [14]
=> 0750-01 [15] => 1311-07 [16] => 1316-01 [17] => 1316-02 [18] => 1316-03
[19] => 278980198657138 [20] => 278980198657139 [21] => 278980198657141 [22]
=> 278980198657142...
I get some data from mysql and try to use both functions that´s in the
subject to test if the code returned by database is in array, but it isn´t
working.
By a for i pass by each register returned by database and print the code and
if it´s in my array, something like this:
for($y=0; $y<$con->count;$y++){
$con->Seek($y);
echo $con->result['cod_loja']." -
".(array_search($con->result['cod_loja'],$_SESSION["cod_loja"])?"Found":"Not
found")."<br>";
}
Here is a part of result of the code above:
0003-01 - Not found
0140-01 - Not found
0141-01 - Not found
0142-01 - Not found
0170-03 - Not found
0181-01 - Not found
0182-04 - Not found
0186-06 - Not found
0186-08 - Not found
0550-01 - Not found
Notice that the code 0003-01 is one code that is in my arrasy, but the
function do not found it.
Could anyone help me in this, please?
Thanks a lot.
--- End Message ---
--- Begin Message ---
[snip]
How much of a performance hit?
[/snip]
Here is an interesting read;
http://mysqldump.azundris.com/archives/36-Serving-Images-From-A-Database
.html
"Your system receives a number of file read requests, requesting it to
load a number of blocks from the disk into the mysqld process.
Eventually, the blocks show up in the buffer cache, and mysqld is woken
up, receiving file data for the read requests."
But I will say this, in this day and age there may not be the
performance hit that we had in days gone by due to improvements in
software and hardware, so I may have misspoken. I do believe in a one
for one comparison where we use PHP and the file system or PHP and MySQL
on the same box that, however minimal, there will be a difference
favoring the file system using the same images.
I also believe that these methods should be compared to using MySQL to
hold data about the image so that the benchmarks could be run like this;
PHP + File System
PHP + MySQL (where MySQL stores a BLOB)
PHP + MySQL (data only) + File System
The reason for the last one is that is the likely way these technologies
would be used together.
I spend a lot of time utilizing the MySQL command line and other similar
query analysis tools for MS-SQL and Oracle. Image BLOBs become more of a
hindrance than a help at this level because these tools are not designed
to properly parse and display the files. This is important because it
adds to my bias against storing images in a database.
--- End Message ---
