php-general Digest 13 Jul 2009 14:04:09 -0000 Issue 6227
Topics (messages 295303 through 295323):
Re: I am RTFM, but still stumbling on how to get built-in functions parsed in
heredoc
295303 by: Paul M Foster
Re: phpscriptor.com
295304 by: Paul M Foster
295307 by: Reese
Re: A prepared statements question
295305 by: Daniel Brown
Re: PHP/mysql equivalent of PEAR's tableInfo()??
295306 by: Zareef Ahmed
295323 by: Govinda
php.ini and cli
295308 by: Ashley Sheridan
295309 by: Eddie Drapkin
295310 by: Stuart
295312 by: Ashley Sheridan
Re: When did you start here? Was - RFC/Survey for Our Newer Folks
295311 by: David Robley
Doubts concerning a general Insert method
295313 by: MEM
295314 by: Stuart
Re: MySql Injection advice
295315 by: Haig Dedeyan
295316 by: Haig Dedeyan
295317 by: tedd
295320 by: tedd
295322 by: Ashley Sheridan
Re: Establishing PHP Session From a Different Host
295318 by: Bob McConnell
295319 by: Ashley Sheridan
295321 by: Andrew Ballard
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 Sat, Jul 11, 2009 at 11:23:11AM -0400, Daniel Brown wrote:
<snip>
>
> I used $html =<<<HTML because it then syntax-highlights as
> HTML+PHP in Vim, and as many know, almost everything I do is from the
> command line and Vim.
Vim FTW! (And mutt for the pwnage!)
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Sat, Jul 11, 2009 at 08:14:35AM -0700, PHPScriptor wrote:
>
> Ok this may look like spam but what the hell...
>
> I'm the owner of phpscriptor.com, I had bigg plans with this domainname
> but... well yes, no time. So I'm selling it. I don't want to make profit out
> of it. So for, lets say 200 dollar, you can have to domainname. And if you
> want, you get the website free with it.
You don't want to make a profit, yet you're selling it for $200? Those
two statements are contradictory.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
Paul M Foster wrote:
On Sat, Jul 11, 2009 at 08:14:35AM -0700, PHPScriptor wrote:
Ok this may look like spam but what the hell...
I'm the owner of phpscriptor.com, I had bigg plans with this domainname
but... well yes, no time. So I'm selling it. I don't want to make profit out
of it. So for, lets say 200 dollar, you can have to domainname. And if you
want, you get the website free with it.
Why am I reminded of the Vincent D'Onofrio "Edgar"-cum-cochroach
character when I read those lines above? I found myself adopting
the cochroach accent as I read the first line. Seriously.
You don't want to make a profit, yet you're selling it for $200? Those
two statements are contradictory.
He has a lot of mouths to feed. Plus if he's been sitting on it,
the $200 might let him break even.
I've learned that much, eh?
SL
--- End Message ---
--- Begin Message ---
2009/7/12 Eddie Drapkin <oorza...@gmail.com>:
>
> This is just my opinion, of course :)
Which is welcome. Preferrably, on the php-db@ list, but welcome
nonetheless. ;-P
--
</Daniel P. Brown>
daniel.br...@parasane.net || danbr...@php.net
http://www.parasane.net/ || http://www.pilotpig.net/
Check out our great hosting and dedicated server deals at
http://twitter.com/pilotpig
--- End Message ---
--- Begin Message ---
On Mon, Jul 13, 2009 at 3:19 AM, Govinda <govinda.webdnat...@gmail.com>wrote:
> On Sat, Jul 11, 2009 at 19:57, Govinda<govinda.webdnat...@gmail.com>
>> wrote:
>>
>>> I have been using PEAR's tableInfo() to remind myself about the columns
>>> in
>>> the table.. but now I want to see as much data as possible about the
>>> table
>>> and its contents *without* using PEAR. (I.e. just using built in stuff
>>> for
>>> mysqli.)
>>>
>>
>> This is not mysqli_#() directly, but just mocked up here in this
>> email. Not guaranteed to work, but should give you the right idea at
>> least. ;-P
>>
>> <?php
>> include('inc/config.php'); // Your configuration
>> include('inc/db.php'); // Your database connection info
>>
>> $sql = "SHOW TABLES";
>>
>> $result = mysql_query($sql);
>>
>> foreach(mysql_fetch_assoc($result) as $k => $v) {
>> $ssql = "DESCRIBE ".mysql_real_escape_string($v);
>> $rresult = mysql_query($ssql);
>> echo "<b>".$k."</b>:<br />\n";
>> echo "<pre>\n";
>> print_r(mysql_fetch_assoc($rresult));
>> echo "</pre>\n";
>> echo "<br />\n";
>> }
>> ?>
>>
>
>
> Dan I get roughly the idea, but alas I am stumped so easily in this new
> ocean.. it frustrates me.
>
> I have this code:
>
> $db_billing=mysqli_connect(localhost,metheuser,mypass,billing);
> if (mysqli_connect_error()) { die("Can't connect: " .
> mysqli_connect_error()); }
mysqli
>
> //$dbname = 'billing';
> $sql = "SHOW TABLES";
>
> $result = mysql_query($sql); // line 53
>
Now mysql, What are you doing?
>
> foreach(mysql_fetch_assoc($result) as $k => $v) { // line 55
> $ssql = "DESCRIBE ".mysql_real_escape_string($v);
> $rresult = mysql_query($ssql);
> echo "<b>".$k."</b>:<br />\n";
> echo "<pre>\n";
> print_r(mysql_fetch_assoc($rresult));
> echo "</pre>\n";
> echo "<br />\n";
> }
>
> Which is just giving these errors:
>
> Warning: mysql_query() [function.mysql-query]: Access denied for user
> 'meee'@'localhost' (using password: NO) in
> /home/meee/public_html/somedir/test.php on line 53
>
> Warning: mysql_query() [function.mysql-query]: A link to the server could
> not be established in /home/meee/public_html/somedir/test.php on line 53
>
> Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL result
> resource in /home/meee/public_html/somedir/test.php on line 55
>
> Warning: Invalid argument supplied for foreach() in
> /home/meee/public_html/somedir/test.php on line 55
>
> --
> I am looking forward to when I have enough of my bearings that I can just
> cruise around all the various docs and figure out my own answers. Now
> there are just so many unknowns, I often can't tell which way to even look
> to solve the issues.
> -G
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Zareef Ahmed :: A PHP Developer in India ( Delhi )
Homepage :: http://www.zareef.net
--- End Message ---
--- Begin Message ---
I have this code:
$db_billing=mysqli_connect(localhost,metheuser,mypass,billing);
if (mysqli_connect_error()) { die("Can't connect: " .
mysqli_connect_error()); }
mysqli
//$dbname = 'billing';
$sql = "SHOW TABLES";
$result = mysql_query($sql); // line 53
Now mysql, What are you doing?
Yes. 3 lashing. Thanks. I am not likely to neglect again
remembering that mysql and mysqli are different and have different
syntax.
unfortunately I am still in over my head enough to have to ask..
Here is what I have now:
$db_billing=mysql_connect(localhost,metheuser,mypass,billing);
if (!$db_billing) { die('Could not connect: ' . mysql_error()); }
$sql = "SHOW TABLES";
$result = mysql_query($sql);
foreach(mysql_fetch_assoc($result) as $k => $v) { //line 62
$ssql = "DESCRIBE ".mysql_real_escape_string($v);
$rresult = mysql_query($ssql);
echo "<b>".$k."</b>:<br />\n";
echo "<pre>\n";
print_r(mysql_fetch_assoc($rresult));
echo "</pre>\n";
echo "<br />\n";
}
giving this error:
Warning: mysql_fetch_assoc(): supplied argument is not a valid MySQL
result resource in /home/meee/public_html/somedir/test.php on line 62
I read about:
-mysql_fetch_assoc
-mysql_query
-SHOW TABLES
but do not see why this should be failing. Why isn't $result a '
valid MySQL result resource'?
-G
--- End Message ---
--- Begin Message ---
Hi All,
Just a quick question. When I make changes in the php.ini, to take effect, I
need to restart the Apache (or other web server) service. What happens with
PHP CLI? Is the php.ini parsed each time the script is called, or is there
something specific which needs resetting? The machine that the PHP CLI is
running on is a Windows machine with no web server.
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Mon, Jul 13, 2009 at 4:48 AM, Ashley
Sheridan<a...@ashleysheridan.co.uk> wrote:
> Hi All,
>
> Just a quick question. When I make changes in the php.ini, to take effect, I
> need to restart the Apache (or other web server) service. What happens with
> PHP CLI? Is the php.ini parsed each time the script is called, or is there
> something specific which needs resetting? The machine that the PHP CLI is
> running on is a Windows machine with no web server.
> --
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
The CLI binary reads and parses php.ini on every initialization.
Try something like
<?php
echo $foo
?>
And then set error_reporting (in php.ini) to E_ALL and see your
warning, then set it to 0 and see nothing.
--- End Message ---
--- Begin Message ---
2009/7/13 Ashley Sheridan <a...@ashleysheridan.co.uk>:
> Just a quick question. When I make changes in the php.ini, to take effect, I
> need to restart the Apache (or other web server) service. What happens with
> PHP CLI? Is the php.ini parsed each time the script is called, or is there
> something specific which needs resetting? The machine that the PHP CLI is
> running on is a Windows machine with no web server.
The php.ini file is read whenever a PHP process is started, so in the
case of the CLI binary that's whenever it's run from the command line.
Long-running scripts will need to be restarted for them to see any
changes.
-Stuart
--
http://stut.net/
--- End Message ---
--- Begin Message ---
On Monday 13 July 2009 10:07:24 Stuart wrote:
> 2009/7/13 Ashley Sheridan <a...@ashleysheridan.co.uk>:
> > Just a quick question. When I make changes in the php.ini, to take
> > effect, I need to restart the Apache (or other web server) service. What
> > happens with PHP CLI? Is the php.ini parsed each time the script is
> > called, or is there something specific which needs resetting? The machine
> > that the PHP CLI is running on is a Windows machine with no web server.
>
> The php.ini file is read whenever a PHP process is started, so in the
> case of the CLI binary that's whenever it's run from the command line.
> Long-running scripts will need to be restarted for them to see any
> changes.
>
> -Stuart
>
> --
> http://stut.net/
Cool. The script I'm running is just scanning a directory structure for new
files, so it's not a long-running one. I just needed to add some email
functionality to it, and had to make some SMTP changes in the php.ini.
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
Ashley Sheridan wrote:
> On Sunday 12 July 2009 15:54:27 Daniel Brown wrote:
>> On Sun, Jul 12, 2009 at 09:45, Ashley Sheridan<a...@ashleysheridan.co.uk>
> wrote:
>> > Yeah, I'll put it down to old age and not my reading laziness!
>>
>> You're just lucky Tedd got to you first, Ash. I was going to
>> fairy-slap you for messing up the rotation! You've been here, what,
>> about a year now? ;-P
>>
>> And here's hoping there will be more to come.
>
> About a year and a half now I think.
>
I just have to take this slightly(?) off topic, as that is expected
behaviour here :-).
I thought I had been around for about five years or so, but a quick search
on marc turned up contributions from me as far back as September 2000
http://marc.info/?l=php-general&m=96822528212538&w=2
On reflection, I suspect that the marc archives may not go back as far as
when I first joined what was then a mailinglist only (I think!). Although I
find contributions to other mailing lists back as far as 1995. $deity, I
must be getting old.
<Checks birth year, notes it was in the first half of last century and goes
off to polish and oil the walking frame>
Cheers
--
David Robley
I have enough trouble single-tasking!
Today is Prickle-Prickle, the 48th day of Confusion in the YOLD 3175.
--- End Message ---
--- Begin Message ---
Hello, I'm trying to understand a general CRUD class that I've seen here:
http://www.phpro.org/classes/PDO-CRUD.html
I'm learning PHP and I have some doubts on this method to generally insert
data into DB. The class name is crud and here is the method:
public function dbInsert($table, $values) {
$this->conn();
$fieldnames = array_keys($values[0]);
$size = sizeof($fieldnames);
$i=1;
//construction of the prepared statment
$sql = "INSERT INTO $table";
$fields = '( ' . implode(' ,', $fieldnames) . ' )';
$bound = '(:' . implode(', :', $fieldnames) . ' )';
$sql .= $fields.' VALUES '.$bound;
//prepares statement e saves it on variable $stmt
$stmt = $this->db->prepare($sql);
foreach($values as vals)
{
$stmt->execute($vals);
}
}
To place values on the DB we do:
$crud = new crud();
$values = array
(
array('animal_name'=>'bruce', 'animal_type'=>'dingo'),
array('animal_name'=>'bruce', 'animal_type'=>'kangaroo'),
);
$crud->dbInsert('animals', $values);
The doubts:
1) Names convention question:
Isn't more correct to call $columname, instead of $fieldname ?
2) Why do we have this?
$i=1
3) Here:
$fieldnames = array_keys($values[0]);
We are keeping on variable $fieldnames, the key value of the $values array,
when this array is on the position 0 ? And what is *actually* the value
returned, considering our array?
$values = array
(
array('animal_name'=>'bruce', 'animal_type'=>'dingo'),
array('animal_name'=>'bruce', 'animal_type'=>'kangaroo'),
);
4) Here:
foreach($values as $vals)
{
$stmt->execute($vals);
}
We are telling that, for each (line/element/index ???) of $values array, the
actual value will be "given"(?) to vals, and the pointer goes to the next
(line/element/index)... ?
We then execute the prepared statement, but I don't get what are we passing
as a param? I mean, what kind of think does the execute PDO method expects
as a param?
Why $stmt->execute($vals); and not only $stmt->execute(); ?
Can I please have your help on clarifying those doubts?
Thanks a lot,
Márcio
--- End Message ---
--- Begin Message ---
2009/7/13 MEM <tal...@gmail.com>:
> Hello, I'm trying to understand a general CRUD class that I've seen here:
> http://www.phpro.org/classes/PDO-CRUD.html
>
> I'm learning PHP and I have some doubts on this method to generally insert
> data into DB. The class name is crud and here is the method:
>
> public function dbInsert($table, $values) {
>
> $this->conn();
>
> $fieldnames = array_keys($values[0]);
>
> $size = sizeof($fieldnames);
>
> $i=1;
>
> //construction of the prepared statment
> $sql = "INSERT INTO $table";
>
> $fields = '( ' . implode(' ,', $fieldnames) . ' )';
>
> $bound = '(:' . implode(', :', $fieldnames) . ' )';
>
> $sql .= $fields.' VALUES '.$bound;
>
> //prepares statement e saves it on variable $stmt
> $stmt = $this->db->prepare($sql);
>
> foreach($values as vals)
> {
> $stmt->execute($vals);
> }
> }
>
>
> To place values on the DB we do:
>
> $crud = new crud();
>
> $values = array
> (
> array('animal_name'=>'bruce', 'animal_type'=>'dingo'),
> array('animal_name'=>'bruce', 'animal_type'=>'kangaroo'),
> );
>
> $crud->dbInsert('animals', $values);
>
>
>
>
>
> The doubts:
> 1) Names convention question:
> Isn't more correct to call $columname, instead of $fieldname ?
The two terms are interchangeable in the context of a database.
> 2) Why do we have this?
> $i=1
It's not used so I'd guess it's a remnant from an older version of the
method. Safe to remove it.
> 3) Here:
> $fieldnames = array_keys($values[0]);
>
> We are keeping on variable $fieldnames, the key value of the $values array,
> when this array is on the position 0 ? And what is *actually* the value
> returned, considering our array?
>
> $values = array
> (
> array('animal_name'=>'bruce', 'animal_type'=>'dingo'),
> array('animal_name'=>'bruce', 'animal_type'=>'kangaroo'),
> );
You can use the var_dump function to dump the contents of $fieldnames
after that line has been executed and see for yourself.
In this case let's break it down...
$values[0] will give you the first element of $values, namely
array('animal_name'=>'bruce', 'animal_type'=>'dingo').
array_keys will return an array containing the keys from the
passed array, so in this case you'll get array('animal_name',
'animal_type').
> 4) Here:
> foreach($values as $vals)
> {
> $stmt->execute($vals);
> }
>
> We are telling that, for each (line/element/index ???) of $values array, the
> actual value will be "given"(?) to vals, and the pointer goes to the next
> (line/element/index)... ?
>
> We then execute the prepared statement, but I don't get what are we passing
> as a param? I mean, what kind of think does the execute PDO method expects
> as a param?
> Why $stmt->execute($vals); and not only $stmt->execute(); ?
After it's finished building $sql use var_dump to look at it. You'll
see that the values are specified as :animal_name and :animal_type.
The : indicates to PDO that these are replaceable values.
The foreach will go through the $values array and for each row it will
pass the data (e.g. array('animal_name'=>'bruce',
'animal_type'=>'dingo') for the first time round the loop) to the
execute function which will effectively replace those elements in the
SQL statement and execute it.
For more info I suggest you Google for "PDO prepared statements" for
further reading.
-Stuart
--
http://stut.net/
--- End Message ---
--- Begin Message ---
On July 12, 2009 03:34:49 pm Haig Dedeyan wrote:
> On Sat, 11 Jul 2009 21:26:36 -0400, Haig Dedeyan wrote:
> >> On Sun, Jul 12, 2009 at 4:09 AM, Haig Dedeyan <hdede...@videotron.ca>
wrote:
> >>> mysql_query("INSERT INTO phonedir
> >>> (fname, lname) VALUES('$new_fname','$new_lname')")
> >>> or die(mysql_error());
> >
> > I won;t be using 2x escapes but I just need to know if I should be seeing
> > the backslash in the dbase.
>
> No, the backslashes should not be stored in the database.
> They are only there to tell the database engine how to
> separate data from the SQL syntax.
>
>
> /Nisse
Ahhh. Thanks for the info.
Cheers
Haig
--- End Message ---
--- Begin Message ---
On July 12, 2009 08:52:56 am Haig Dedeyan wrote:
> At 6:39 PM -0400 7/11/09, Haig Dedeyan wrote:
>
> [1]
>
> >mysql_query("INSERT INTO phonedir
> >(fname, lname) VALUES('$new_fname','$new_lname')")
> >or die(mysql_error());
> >
> >or
>
> [2]
>
> >mysql_query("INSERT INTO phonedir
> >(fname, lname)
> >VALUES('".mysql_real_escape_string($new_fname)."','".mysql_real_escape_str
> >ing($new_lname)."')") or die(mysql_error());
>
> I always do [1] and NOT [2].
>
> The reason for this is that when I clean and scrub data prior to
> insertion, I may do more than pass it through a
> mysql_real_escape_string() function.
>
> For example, I may want to trim() it; or check if it's a valid email
> address; or check if it's a number; or do any number of other checks
> prior to insertion. I don't want to place all those functions into a
> query, so why place one?
>
> Lastly, I think [1] is easier to read than [2].
>
> That's my take.
>
> Cheers,
>
> tedd
>
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
Thanks. Yes I agree [1] is the better way to go.
After reading Nisse's response, it looks like the backslashes are never stored
in the table so all is good for me.
Thanks to everyone to helped out.
Cheers
Haig
--- End Message ---
--- Begin Message ---
At 8:50 PM +0530 7/12/09, Zareef Ahmed wrote:
On Sun, Jul 12, 2009 at 8:42 PM, tedd
<<mailto:tedd.sperl...@gmail.com>tedd.sperl...@gmail.com> wrote:
As with all communication, it's better to be clear than obtuse.
Agree, but I believe "obtuse" word meaning is contextual and depends :)
The word "obtuse" can mean "difficult to understand" or "stupid"
depending upon context. Considering the context of my post was
addressing difficulties in understanding your replies to postings, I
think it proper to use the word in the manner I did. However, if you
wish to take the other meaning, then that's your choice.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
At 3:53 PM -0400 7/12/09, Paul M Foster wrote:
On Sun, Jul 12, 2009 at 09:07:45AM -0400, tedd wrote:
<snip>
As for prepared statements, I'm no authority on them, but from what
I've read they are not going to be something I'll be practicing
anytime soon.
Aside from Stuart's comments about slowness, what else have you read
that makes you discount the use of prepared statements? The PDO class
emphasizes that you're safe from SQL injection exploits, which seems a
big plus.
Paul
Paul:
As I said, I'm no authority. However as I have read, prepared
statements are for a limited set of instructions in MySQL. They can't
be used for everything. Why should I learn one way to do something
that isn't universal in the language?
Additionally, I think the way I sanitize data is sufficient AND I
understand it. *My* learning curve may introduce security problems
that I am not willing to risk, at this moment. As I said, I have more
than enough on my plate to digest -- including learning non-prepared
statements in MySQL.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
On Monday 13 July 2009 14:31:09 tedd wrote:
> At 3:53 PM -0400 7/12/09, Paul M Foster wrote:
> >On Sun, Jul 12, 2009 at 09:07:45AM -0400, tedd wrote:
> >
> ><snip>
> >
> >> As for prepared statements, I'm no authority on them, but from what
> >> I've read they are not going to be something I'll be practicing
> >> anytime soon.
> >
> >Aside from Stuart's comments about slowness, what else have you read
> >that makes you discount the use of prepared statements? The PDO class
> >emphasizes that you're safe from SQL injection exploits, which seems a
> >big plus.
> >
> >Paul
>
> Paul:
>
> As I said, I'm no authority. However as I have read, prepared
> statements are for a limited set of instructions in MySQL. They can't
> be used for everything. Why should I learn one way to do something
> that isn't universal in the language?
>
> Additionally, I think the way I sanitize data is sufficient AND I
> understand it. *My* learning curve may introduce security problems
> that I am not willing to risk, at this moment. As I said, I have more
> than enough on my plate to digest -- including learning non-prepared
> statements in MySQL.
>
> Cheers,
>
> tedd
>
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
Generally speaking, what I have always done to avoid MySQL injection is to use
mysql_real_escape_string() on all variables I'm chucking into the database.
This won't avoid hacks that involve people trying to insert other types of
code into your content, aka XSS, et al, though. What I do for cases like
these is try to be as specific as possible when allowing users to enter data
and try to sanitise it as much as possible.
For example, a name field shouldn't contain anything other than letters, so
you can write a regex for that. Phone number fields should only contain
numbers, the odd + sign, and sometimes spaces and brackets if you're users
are really fastidious with their input.
Sometimes this isn't possible, as in the case of a lot of free-text entry
boxes, so for those you should try and make some attempt to strip out tags or
html encode the data prior to displaying it.
Anyway, that's my take on it, and it seems to work for me, but I'm always
welcome to know of other ways, as I'd prefer being told on the list than
finding out the hard way! :p
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
From: Daniel Kolbo
> Daniel Brown wrote:
>> On Sun, Jul 12, 2009 at 12:37, Daniel Kolbo<kolb0...@umn.edu> wrote:
>>> Hello,
>>>
>>> How does one continue a php session on a different domain (domain B)
>>> than the domain (domain A) that started the session?
>>
>> Simple answer: you don't.
>>
>
> Thanks for the responses.
>
> Re: Simple answer
> I thought of another example. My bank's website. I sign-in and
> authenticate with "bank.com". Then, i click credit card from bank.com
> and i'm redirected to "creditcard.com" without me having to reinput
> user/pass. They clearly do it (granted they have a lot more resources
> then I do, but i'd still like to know how they are doing it).
My bank also does this, but it only works if Javascript is enabled when
I first log in. Otherwise the initial login fails and I do it again on
the second site. I haven't actually looked at the page sources to see
what they do. But I have NoScript configured to block all JS by default
so the initial login attempt always fails. It also reports blocked XSS
attempts on both pages. So whatever they are doing does not appear to be
very safe.
Bob McConnell
--- End Message ---
--- Begin Message ---
On Monday 13 July 2009 14:15:18 Bob McConnell wrote:
> From: Daniel Kolbo
>
> > Daniel Brown wrote:
> >> On Sun, Jul 12, 2009 at 12:37, Daniel Kolbo<kolb0...@umn.edu> wrote:
> >>> Hello,
> >>>
> >>> How does one continue a php session on a different domain (domain B)
> >>> than the domain (domain A) that started the session?
> >>
> >> Simple answer: you don't.
> >
> > Thanks for the responses.
> >
> > Re: Simple answer
> > I thought of another example. My bank's website. I sign-in and
> > authenticate with "bank.com". Then, i click credit card from bank.com
> > and i'm redirected to "creditcard.com" without me having to reinput
> > user/pass. They clearly do it (granted they have a lot more resources
> > then I do, but i'd still like to know how they are doing it).
>
> My bank also does this, but it only works if Javascript is enabled when
> I first log in. Otherwise the initial login fails and I do it again on
> the second site. I haven't actually looked at the page sources to see
> what they do. But I have NoScript configured to block all JS by default
> so the initial login attempt always fails. It also reports blocked XSS
> attempts on both pages. So whatever they are doing does not appear to be
> very safe.
>
> Bob McConnell
Just a thought, but as the session ID normally gets automatically added to the
header request by a browser, could you not add it into the form itself as you
move from one domain to another?
Afaik, PHP tends to prefer the PHPSESSID as an element in the $_COOKIE array
(or the $_REQUEST array which is made up from the cookie as well) so you
might be able to do some clever playing around to achieve the effect?
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Mon, Jul 13, 2009 at 9:15 AM, Bob McConnell<r...@cbord.com> wrote:
> From: Daniel Kolbo
>> Daniel Brown wrote:
>>> On Sun, Jul 12, 2009 at 12:37, Daniel Kolbo<kolb0...@umn.edu> wrote:
>>>> Hello,
>>>>
>>>> How does one continue a php session on a different domain (domain B)
>>>> than the domain (domain A) that started the session?
>>>
>>> Simple answer: you don't.
>>>
>>
>> Thanks for the responses.
>>
>> Re: Simple answer
>> I thought of another example. My bank's website. I sign-in and
>> authenticate with "bank.com". Then, i click credit card from bank.com
>> and i'm redirected to "creditcard.com" without me having to reinput
>> user/pass. They clearly do it (granted they have a lot more resources
>> then I do, but i'd still like to know how they are doing it).
>
> My bank also does this, but it only works if Javascript is enabled when
> I first log in. Otherwise the initial login fails and I do it again on
> the second site. I haven't actually looked at the page sources to see
> what they do. But I have NoScript configured to block all JS by default
> so the initial login attempt always fails. It also reports blocked XSS
> attempts on both pages. So whatever they are doing does not appear to be
> very safe.
>
> Bob McConnell
>
I have seen cases where site A to renders a form whose action points
to site B with credentials for site B in hidden form elements. Since
there are no visible UI elements, it requires Javascript to trigger
the form to submit itself. If the credentials are simply the username
and password, this seems pretty insecure to me.
I'm not sure how much more secure you can make it if you use a
one-time token (possibly one that encodes the client's IP address with
some other server-side information into a hash?). For this to work,
the two systems would have to be able to communicate either through
shared data storage or some sort of behind-the-scenes web service.
It can also fail in cases where the form processor on site B depends
on some previous state being established with the browser (for
example, a particular cookie that must already be set, or only
accepting posts with a "valid" HTTP_REFERER value) before posting the
credentials.
Andrew
--- End Message ---
