> > How is 3 different from 1?
> 1: http://www.somedomain.com/program.php?parm1=value1
> 3: http://www.somedomain.com/program.php/value1
> $PATF_INFO now contains '/value1'
Ahh.
> This is pretty much acceptable to search engines. Even better add:
> <Location /program>
> ForceType application/x-httpd-php
> </Location>
> to httpd.conf. Then the following url will work:
> http://www.somedomain.com/program/value1/value2/command.php
> program _is_ the program. $PATH_INFO containls:
> '/value1/value2/command.php'
I've tried setting this up, but for the life of me, I could not get it to
work.
I've just settled with including the ".php" after the program name and that
works just as well...
http://www.somedomain.com/program.php/value1/value2/command.php
----------------------------------^^^^^^^^^^
> Which you can: $Params = explode( '/', $PATH_INFO ); and
> get an array:
> $Params[0] : value1
> $Params[1] : value2
> $Params[2] : command.php
Yup. I do this, but using the above.
> > > Why do you want to eliminate all get params and cookies?
> > > That might
> > > have a lot of control as to what the best approach will be.
> > GET because they can be modified and
> So can these URL based param passing schemes. Even POST
> params are not all that secure from a determined hacker. All it
> takes is a little work with a program to fake POST values. The
> only advantage they have is taking a little more work.
Yes, I know. But that little extra work is enough. Plus, we are
going to try a few things (including encrypting; not one way)
the hidden variables. That and trying to make sure that the form
submission request originated from our server. I'm still trying to
find the answer as to when HTTP_REFERER is available and
when it isn't... still haven't heard anything back on that one...
> > Cookies because not all users will have them turned on.
> Good reason.
> If you don't care about serach engines, you can just use PHP4 sessions,
> and append the session ID, or compile with --enable-trans-sid and let
> php use cookies when available or place the session ID in the URN if
> they are not.
As I've mentioned in another post, this is *not* working. We have that
directive turned on/compiled in and it still does not append the session ID
to URLs if the user's browser does not accept cookies. I submitted a few
code samples last week that I set up to demonstrated this. Everything
looks ok in the php.ini and everything that needed to be was turned on
when PHP4 (we are using 4.0.3pl1) was compiled, but still the session ID
is not being appended to the URL.
I wish I knew what was wrong.
Chris
