php-general Digest 20 May 2008 09:35:39 -0000 Issue 5469
Topics (messages 274537 through 274551):
Re: Semi-OT: PHP Login with client security
274537 by: Per Jessen
274538 by: Tim Thorburn
274539 by: Tim Thorburn
274540 by: David Giragosian
274542 by: Richard Heyes
274543 by: Robert Cummings
274544 by: Richard Heyes
274545 by: Wolf
274546 by: Wolf
274547 by: robert
Re: fsockopen on ssl://
274541 by: bob pilly
Re: Dead code
274548 by: Shawn McKenzie
0T - Request for quick test
274549 by: Ryan S
274550 by: Daniel Brown
Help Call Javascript Methods Inside PHP
274551 by: Shelley
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 ---
Wolf wrote:
> ---- Per Jessen <[EMAIL PROTECTED]> wrote:
>> Wolf wrote:
>>
>>> ... since IE is more stringent then other browsers ...
>> You are either using a very unusual IE or you are on another planet.
>>
>
> Nope IE and Opera both wait for full page before displaying (while
> firefox displays as output)
I'm not sure what that's got to do with being stringent? I take it you
meant stringent as in the interpretation of standards.
>and IE has always been more stringent in-so-far as displaying things
>that match up to THEIR standards instead of industry or
>fly-by-your-seat coding (accidentally leaving off a closing tag)
>then Mozilla and Firefox have historically been.
Microsoft has never published THEIR standards, so how do you determine
how stringent IE is in adherering to them?
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
Wolf wrote:
---- Tim Thorburn <[EMAIL PROTECTED]> wrote:
Hi all,
Having a slight problem with a demo I gave at a clients last week -
looking for a little advise. Part of my demo involved a password
protected area - the simplified process is: client enters password on
login page > if login/password match encrypted database, PHP session is
created, form forwards to a secured area > secured area checks to make
sure PHP session is valid > if valid display content, if not, return to
login screen.
This procedure is what I've used for many years, tested on a variety of
servers and connections. It works. During the demo with my client, I
was able to enter login/password info, the PHP session was created -
however the screen would not forward to the secured area. Instead I was
pretended with a blank screen (client only has an outdated/non-updated
version of IE6). If I were to type in the URL to the secured area, it
would display content properly. As a test, I logged out, closed my
browser and started again, this time entering an incorrect
login/password - again it would not forward to the next screen properly,
however this time when I typed in the full URL, it would not display as
the session hadn't been created.
I've spoken briefly with my clients IT person, however he's unwilling to
share any firewall information or really anything regarding their
security setup - which I understand as I'm not an employee and just a
contractor.
So, after long winded description - does anyone with network security
experience have any idea either a) what I would need to ask the IT
person to allow for their site only, or b) have any suggestions for
alternate password authentication that may work given the above conditions?
TIA
-Tim
It sounds like your code is hokey, since IE is more stringent then other
browsers, the code looks to be at fault.
What browsers did you test this with before taking it to the client?
Firewalls shouldn't be any type of issue at all in this case, unless your browser is trying to redirect to another port, in which case, that should be something that the firewall won't affect internally anyways.
So all roads point back to code failure.
Wolf
The code has been tested on Win2k, XP, Vista, Linux and OSX - IE5.x,
IE6.x, IE7, Netscape 9, Firefox 2, Firefox 5 beta 5, and Safari. Works
on a variety of connections and locations outside of the clients office
- does not work inside the clients office.
--- End Message ---
--- Begin Message ---
robert wrote:
On May 18, 2008, at 10:14 PM, Tim Thorburn wrote:
Hi all,
Having a slight problem with a demo I gave at a clients last week -
looking for a little advise. Part of my demo involved a password
protected area - the simplified process is: client enters password on
login page > if login/password match encrypted database, PHP session
is created, form forwards to a secured area > secured area checks to
make sure PHP session is valid > if valid display content, if not,
return to login screen.
This procedure is what I've used for many years, tested on a variety
of servers and connections. It works. During the demo with my
client, I was able to enter login/password info, the PHP session was
created - however the screen would not forward to the secured area.
Instead I was pretended with a blank screen (client only has an
outdated/non-updated version of IE6). If I were to type in the URL
to the secured area, it would display content properly. As a test, I
logged out, closed my browser and started again, this time entering
an incorrect login/password - again it would not forward to the next
screen properly, however this time when I typed in the full URL, it
would not display as the session hadn't been created.
I've spoken briefly with my clients IT person, however he's unwilling
to share any firewall information or really anything regarding their
security setup - which I understand as I'm not an employee and just a
contractor.
So, after long winded description - does anyone with network security
experience have any idea either a) what I would need to ask the IT
person to allow for their site only, or b) have any suggestions for
alternate password authentication that may work given the above
conditions?
TIA
-Tim
try to use a full url instead of relative. e.g.
header('location: thankyou.php');
vs.
header('location: http://www.mysite.com/thankyou.php');
or use $_SERVER['DOCUMENT_ROOT'] for portability.
i think this is some weirdness on IE6. this worked for me.
I'll try $_SERVER['DOCUMENT_ROOT'] during my next demonstration which
should be sometime next week. Odd that this issue has never come up
before O.o
--- End Message ---
--- Begin Message ---
On 5/19/08, Tim Thorburn <[EMAIL PROTECTED]> wrote:
> Wolf wrote:
> > ---- Tim Thorburn <[EMAIL PROTECTED]> wrote:
> >
> > > Hi all,
> > >
> > > Having a slight problem with a demo I gave at a clients last week -
> looking for a little advise. Part of my demo involved a password protected
> area - the simplified process is: client enters password on login page > if
> login/password match encrypted database, PHP session is created, form
> forwards to a secured area > secured area checks to make sure PHP session is
> valid > if valid display content, if not, return to login screen.
> > >
> > > This procedure is what I've used for many years, tested on a variety of
> servers and connections. It works. During the demo with my client, I was
> able to enter login/password info, the PHP session was created - however the
> screen would not forward to the secured area. Instead I was pretended with
> a blank screen (client only has an outdated/non-updated version of IE6). If
> I were to type in the URL to the secured area, it would display content
> properly. As a test, I logged out, closed my browser and started again,
> this time entering an incorrect login/password - again it would not forward
> to the next screen properly, however this time when I typed in the full URL,
> it would not display as the session hadn't been created.
> > >
> > > I've spoken briefly with my clients IT person, however he's unwilling to
> share any firewall information or really anything regarding their security
> setup - which I understand as I'm not an employee and just a contractor.
> > >
> > > So, after long winded description - does anyone with network security
> experience have any idea either a) what I would need to ask the IT person to
> allow for their site only, or b) have any suggestions for alternate password
> authentication that may work given the above conditions?
> > >
> > > TIA
> > > -Tim
> > >
> > >
> >
> > It sounds like your code is hokey, since IE is more stringent then other
> browsers, the code looks to be at fault.
> >
> > What browsers did you test this with before taking it to the client?
> > Firewalls shouldn't be any type of issue at all in this case, unless your
> browser is trying to redirect to another port, in which case, that should be
> something that the firewall won't affect internally anyways.
> > So all roads point back to code failure.
> >
> > Wolf
> >
> >
> The code has been tested on Win2k, XP, Vista, Linux and OSX - IE5.x, IE6.x,
> IE7, Netscape 9, Firefox 2, Firefox 5 beta 5, and Safari. Works on a
> variety of connections and locations outside of the clients office - does
> not work inside the clients office.
>
Someone suggested looking at the error logs. That still seems like a good idea.
David
--- End Message ---
--- Begin Message ---
Because it is RFC.
Since when has that mattered? :-)
--
Richard Heyes
Employ me
http://www.phpguru.org/cv
+----------------------------------------+
| Access SSH with a Windows mapped drive |
| http://www.phpguru.org/sftpdrive |
+----------------------------------------+
--- End Message ---
--- Begin Message ---
On Mon, 2008-05-19 at 21:03 +0100, Richard Heyes wrote:
> > Because it is RFC.
>
> Since when has that mattered? :-)
Always... unless you're one of the ignorant masses ;)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
On Mon, 2008-05-19 at 21:03 +0100, Richard Heyes wrote:
Because it is RFC.
Since when has that mattered? :-)
Always... unless you're one of the ignorant masses ;)
Whatever works... :-)
--
Richard Heyes
Employ me
http://www.phpguru.org/cv
+----------------------------------------+
| Access SSH with a Windows mapped drive |
| http://www.phpguru.org/sftpdrive |
+----------------------------------------+
--- End Message ---
--- Begin Message ---
--- Per Jessen <[EMAIL PROTECTED]> wrote:
> Wolf wrote:
>
> > ---- Per Jessen <[EMAIL PROTECTED]> wrote:
> >> Wolf wrote:
> >>
> >>> ... since IE is more stringent then other browsers ...
> >> You are either using a very unusual IE or you are on another planet.
> >>
> >
> > Nope IE and Opera both wait for full page before displaying (while
> > firefox displays as output)
>
> I'm not sure what that's got to do with being stringent? I take it you
> meant stringent as in the interpretation of standards.
yup! ;)
> >and IE has always been more stringent in-so-far as displaying things
> >that match up to THEIR standards instead of industry or
> >fly-by-your-seat coding (accidentally leaving off a closing tag)
> >then Mozilla and Firefox have historically been.
>
> Microsoft has never published THEIR standards, so how do you determine
> how stringent IE is in adherering to them?
That was essentially my point. :P
Wolf
--- End Message ---
--- Begin Message ---
<!-- snip -->
It sounds like your code is hokey, since IE is more stringent then
other browsers, the code looks to be at fault.
What browsers did you test this with before taking it to the client?
Firewalls shouldn't be any type of issue at all in this case, unless
your browser is trying to redirect to another port, in which case,
that should be something that the firewall won't affect internally
anyways.
So all roads point back to code failure.
Wolf
The code has been tested on Win2k, XP, Vista, Linux and OSX - IE5.x,
IE6.x, IE7, Netscape 9, Firefox 2, Firefox 5 beta 5, and Safari. Works
on a variety of connections and locations outside of the clients office
- does not work inside the clients office.
Still, your code should be portable, so unless you are kicking it around
different servers from a localhost to an outside host, your going to be
dealing with hokey code...
In other words, if you brought your demo in on your laptop, powered it
up and got a network connection, all your stuff locally stored on the
machine ran and then going to the server didn't, then something in your
code is stopping the process, and without looking at your server logs,
then you have to go back and examine your code for the authorization
pieces to make sure that your failures are putting SOMETHING to the
screen when it dies.
But if that is the case, it's still coding failure and shouldn't be
something that is noticeable.
Based off your description of the issue, it's code, plain and simple.
No network issues should be an issue unless you are trying to bounce
through different ports and different locations. And if that is the
case and the client would have to open their firewall just to run your
application, they'll look elsewhere.
Grab your log files for that timeframe and start digging through them.
Your best bet in nipping it in the bud before failing again in front of
them is there.
Wolf
--- End Message ---
--- Begin Message ---
On May 19, 2008, at 12:20 PM, Tim Thorburn wrote:
robert wrote:
On May 18, 2008, at 10:14 PM, Tim Thorburn wrote:
Hi all,
Having a slight problem with a demo I gave at a clients last week
- looking for a little advise. Part of my demo involved a
password protected area - the simplified process is: client enters
password on login page > if login/password match encrypted
database, PHP session is created, form forwards to a secured area
> secured area checks to make sure PHP session is valid > if valid
display content, if not, return to login screen.
This procedure is what I've used for many years, tested on a
variety of servers and connections. It works. During the demo
with my client, I was able to enter login/password info, the PHP
session was created - however the screen would not forward to the
secured area. Instead I was pretended with a blank screen (client
only has an outdated/non-updated version of IE6). If I were to
type in the URL to the secured area, it would display content
properly. As a test, I logged out, closed my browser and started
again, this time entering an incorrect login/password - again it
would not forward to the next screen properly, however this time
when I typed in the full URL, it would not display as the session
hadn't been created.
I've spoken briefly with my clients IT person, however he's
unwilling to share any firewall information or really anything
regarding their security setup - which I understand as I'm not an
employee and just a contractor.
So, after long winded description - does anyone with network
security experience have any idea either a) what I would need to
ask the IT person to allow for their site only, or b) have any
suggestions for alternate password authentication that may work
given the above conditions?
TIA
-Tim
try to use a full url instead of relative. e.g.
header('location: thankyou.php');
vs.
header('location: http://www.mysite.com/thankyou.php');
or use $_SERVER['DOCUMENT_ROOT'] for portability.
i think this is some weirdness on IE6. this worked for me.
I'll try $_SERVER['DOCUMENT_ROOT'] during my next demonstration
which should be sometime next week. Odd that this issue has never
come up before O.o
Actually i think you might be experiencing the P3P privacy policy
thing. I tried it myself but couldn't get the headers to cooperate;
only worked when i appended the session id to the url. I hope someone
here can chime in on it.
Google keywords "php session ie6" or "ie6 cookies". i'd also recommend
a helmet, facemask and bullwhip.
--- End Message ---
--- Begin Message ---
Hi
Apache is serving php correctly and i can see this from a <?php phpinfo(); ?>
and everything else works fine just this one call to fsockopen using ssl://. Is
there some sort of extra configuration required for apache to be able to do
this that i am not aware of?
Bob
----- Original Message ----
From: Ólafur Waage <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Monday, 19 May, 2008 10:26:58 AM
Subject: Re: [PHP] Re: fsockopen on ssl://
Are you doing the command line on the same machine as the server?
Have you checked out the apache configuration? Since phpcli runs alone. (iirc)
2008/5/18 bob pilly <[EMAIL PROTECTED]>:
> Hi Manuel
>
> Thanks for the reply. I have tested it with a timeout of 20 seconds and the
> same thing occurs. It works as before from the command line and not form
> within apache.. Any more ideas?
>
> Cheers
>
> Bob
>
>
> ----- Original Message ----
> From: Manuel Lemos <[EMAIL PROTECTED]>
> To: bob pilly <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Sent: Wednesday, 14 May, 2008 4:26:41 PM
> Subject: Re: fsockopen on ssl://
>
> Hello,
>
> on 05/13/2008 04:37 PM bob pilly said the following:
>> Hi all
>>
>> I have tried researching this issue but havent come up with any solution so
>> im hoping someone has seen it before and can help. I have the following test
>> script that uses fsockopen to connect to a https site, get the contents and
>> outputs it.
>>
>> <?php
>> $host = "www.microsoft.com";
>> $path = "/";
>> $fh = fsockopen("ssl://".$host, 443, $errno, $errstr, 5);//opens url for
>> reading with a timeout of 2 seconds
>>
>> if (!$fh){
>> echo "FAIL: $errno $errstr ";
>> }
>> else{
>> $out = "GET $path HTTP/1.1\r\n";
>> $out .= "Host: $host\r\n";
>> $out .= "Connection: Close\r\n";
>> $out .= "\r\n";
>> fwrite($fh, $out);
>> stream_set_timeout($fh,2);
>> $info = stream_get_meta_data($fh);
>> if($info['timed_out']){
>> echo "TIMEOUT\n";
>> }
>> else{
>> $haystack = "";
>> while (!feof($fh)) {
>> $haystack.= fgets($fh, 4096);
>> }
>> }
>> print $haystack;
>> fclose($fh);
>> }
>> ?>
>>
>> if i run this script using php -f test.php it works fine. However if i try
>> and run this on my loca apache server i get the following error:
>>
>> Warning: fsockopen() [function.fsockopen]:unable to connect to
>> ssl://www.microsoft.com:443 (A connection attemptfailed because the
>> connected party did not properly respond after aperiod of time, or
>> established connection failed because connected hosthas failed to respond.)
>> in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\test.php on
>> line 4
>> FAIL: 10060 A connection attempt failed because the connected party didnot
>> properly respond after a period of time, or established connectionfailed
>> because connected host has failed to respond.
>>
>> As you can see from that error i am using windows and apache 2.2. My php
>> version is 5.25. I have Registered Stream Socket Transports tcp, udp, ssl,
>> sslv3, sslv2, tlsin my config.
>
> I suspect that you are giving a very short timeout but then you are not
> handling the timeout error properly.
>
> Anyway, before reinventing the wheel, you may to try this HTTP client
> class that supports many options including establishing SSL corrections
> and setting and handling timeouts correctly.
>
> http://www.phpclasses.org/httpclient
>
> --
>
> Regards,
> Manuel Lemos
>
> PHP professionals looking for PHP jobs
> http://www.phpclasses.org/professionals/
>
> PHP Classes - Free ready to use OOP components written in PHP
> http://www.phpclasses.org/
>
>
>
> __________________________________________________________
> Sent from Yahoo! Mail.
> A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
__________________________________________________________
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
--- End Message ---
--- Begin Message ---
Eric Butera wrote:
On Mon, May 19, 2008 at 11:06 AM, Aschwin Wesselius
<[EMAIL PROTECTED]> wrote:
Hello list,
Is there anyone having experience with finding "dead code" in their library
/ application?
Dead code as in unused variables, uncalled methods, uncalled functions,
undeclared classes etc.
Any help on examples, resources etc. is much appreciated.
--
Aschwin Wesselius
/'What you would like to be done to you, do that to the other....'/
Maybe this will help http://xdebug.org/docs/code_coverage
Zend studio has the same type of feature if you use it.
-Shawn
--- End Message ---
--- Begin Message ---
Hey guys,
Just make a egreeting app and need people to just test the AJAXy upload that i
have on the form, if you have any problems please tell me.. if it goes smooth
please tell me... as usual, any comments and suggestions too would be
appreciated.
This is the form:
http://www.ezee.se/ezee-ecard-egreetings/step2_v2.php
All i want you to do is click the above link, click the file/browse button and
try to upload a .jpg/jpeg image...
Thanks in advance!
Ryan
P.S section is not yet open & am still testing stuff so dont try to create any
egreetings right now :)
--- End Message ---
--- Begin Message ---
On Tue, May 20, 2008 at 12:01 AM, Ryan S <[EMAIL PROTECTED]> wrote:
>
>
> Hey guys,
>
> Just make a egreeting app and need people to just test the AJAXy upload that
> i have on the form, if you have any problems please tell me.. if it goes
> smooth please tell me... as usual, any comments and suggestions too would be
> appreciated.
Looks like it worked, Ryan. One suggestion, though: instead of
the button next to the green arrow, why not use something like this
instead?
<input type="image" name="submitGraphic" id="submitGraphic"
src="/path/to/image.png" value="Click!" />
--
</Daniel P. Brown>
Dedicated Servers - Intel 2.4GHz w/2TB bandwidth/mo. starting at just
$59.99/mo. with no contract!
Dedicated servers, VPS, and hosting from $2.50/mo.
--- End Message ---
--- Begin Message ---
Hi all,
How can I call a javascript method inside PHP?
That is:
Suppose there is a js file: http://someurl/somejs.js
There are some js methods in that js file,
I want to include that js into PHP and call its methods.
Is it possible?
If it is, how?
Thank you very much.
--
Regards,
Shelley
--- End Message ---
