Addressed to: "Boget, Chris" <[EMAIL PROTECTED]>
[EMAIL PROTECTED]
** Reply to note from "Boget, Chris" <[EMAIL PROTECTED]> Mon, 5 Mar 2001 08:25:25
-0600
> > 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 never had a problem with it. I place it inside the <VirtualHost>
block for the host I want to affect. I've got some domains with over
half a dozen different programs that use this trick. It needs to match
the AddType value you use to enable .php, .php3, .phtml, etc to run php.
It may only work for Apache modules. Of course, you also have to reload
the web server config files after you add it. apachectrl graceful, or
apachectl restart at least.
> 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
> ----------------------------------^^^^^^^^^^
That works, but doesn't look as cool.
> > > > 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.
To make sure hidden fields stay unchanged, contat all the values
together into a long string, pass the string to md5, and store the
result as a checksum. When you get data back from the browser concat it
again, not including the md5 string, and compare it with the checksum
from the hidden values. If they are different someone has changed the
data.
You should to add something somewhat random, that only the server knows,
into the md5 input, so even an ex-employee who knows the algorithm can
not fake a checksum. The md5 checksum with a local secret is a good way
to make sure that the original md5 checksum was computed by one of your
machines. A hacker would need to know that to create a valid checksum
for modified data.
> 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...
>
It depends on the browser. Some never send it. The ones that do
usually only send it when a link is clicked on a page. URLS entered
by clicking on a link in an email, selected from bookmarks or typed in
by hand never have a referer.
> > > 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.
>
If you are creating the links dynamicly how about adding this near the
end of the process:
if( empty( $HTTP_COOKIE_VARS[ 'phpsessid' ] ))
echo '?phpsessid=', session_id();
Crude, but it should be effective.
There was a php bug that messed up enable-trans-sid when I first
started using sessions, so I wrote a function to create a link:
function anchor( $Title, $Href, $Params='', Anchor='', Target='' ) {
}
It kind of outputs something like:
<A href="$Href?$Params#$Anchor" target="$Target">$Title</A>
except that it only includes the target= part if $Target is not empty,
and only includes $Params if it is not empty. If( session_id() > 0 AND
empty( $HTTP_COOKIE_VARS[ 'phpsessid' ] ) it adds 'phpsessid=' .
session_id() to $Params, with ? in front of it if $Parms was empty or
& if it had a value.
I still use it in most of my php pages. Most of my links look like:
<? anchor( 'Home', "http://$SERVER_NAME/" ) ?>
That might be the quickest thing to do.
> Chris
Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]