RE: [PHP] HREFs that can't be

From: Date: Mon, 05 Mar 2001 14:26:32 +0000
Subject: RE: [PHP] HREFs that can't be
Groups: php.general 
Request: Send a blank email to php-general+get-42613@lists.php.net to get a copy of this message
> > 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

« previous php.general (#42613) next »