I'm installing this on my own machine. I have apache 2.0.48 and php4.
Apparently the php3 extension is not supported. I've tried various
methods I know of, but it won't work.
Renaming the files to .php does seem to work
I can only see the source of install.php3, nothing else.
--
Is this really happening?
Have you tried to add .php3 to the "AddType application" command in httpd.conf?
George
Philip S Tellis wrote:
I'm installing this on my own machine. I have apache 2.0.48 and php4. Apparently the php3 extension is not supported. I've tried various methods I know of, but it won't work.
Renaming the files to .php does seem to work
I can only see the source of install.php3, nothing else.
On Tue, 13 Jan 2004, George Kandalaft wrote:
Have you tried to add .php3 to the "AddType application" command in
httpd.conf?
That only affects the type returned to the browser. The fact is that
the file isn't being passed to php at all.
I fixed it by changing the Files section in /etc/httpd/conf.d/php.conf
from:
<Files *.php>
...
</Files>
<Files *.php3>
...
</Files>
to:
<Files ~ "\.php3?$">
...
</Files>
Thanks.
Now I have one more question. When logging in (using lynx), it tells me
to enable javascript to increase security and ensure that data is not
sent unencrypted over the network.
This however does not increase security. In order to log in to the
site, the only thing required is the data sent from the client to the
server. If the client sends an MD5 hash, then we only require that MD5
hash. We do not require the real password.
I think it would still be possible to forge a login, even if the snooper
does not know the real password.
Only safe bet is to use SSL.
Philip
--
Don't tell any big lies today. Small ones can be just as effective.
At 14:06 13.01.04 +0000, George Kandalaft wrote:
Have you tried to add .php3 to the "AddType application" command in
httpd.conf?
just to illustrate it a bit further: on my Debian box (with Apache 1.3.26)
/etc/apache/httpd.conf looks reads
# AddType allows you to tweak mime.types without actually editing
# it, or to make certain files to be certain types.
#
# For example, the PHP 3.x module (not part of the Apache
# distribution - see http://www.php.net) will typically use:
#
AddType application/x-httpd-php .php3
#AddType application/x-httpd-php3-source .phps
#
# And for PHP 4.x, use:
#
AddType application/x-httpd-php .php
#AddType application/x-httpd-php-source .phps
I'm installing this on my own machine. I have apache 2.0.48 and php4.
Apparently the php3 extension is not supported. I've tried various
methods I know of, but it won't work.Renaming the files to .php does seem to work
I can only see the source of install.php3, nothing else.
Good luck,
Peter
Now I have one more question. When logging in (using lynx), it tells me
to enable javascript to increase security and ensure that data is not
sent unencrypted over the network.
Indeed and it works. It's not perfect, but let me explain.
This however does not increase security. In order to log in to the
site, the only thing required is the data sent from the client to the
server. If the client sends an MD5 hash, then we only require that MD5
hash. We do not require the real password.
Yes. However the hash itself changes at every login, the password does not.
Furthermore the hash opens a session that is tied to the IP address. If the
IP address used by the snooper is not the same, the hash will be renewed (no
hard disconnection, because it can be the same person changing IP on the
fly), and one of the attacker or the attacked will be disconnected. If it is
the attacker, good, if the is the attacked, then at least s/he'll have an
idea that "there is a problem".
I think it would still be possible to forge a login, even if the snooper
does not know the real password.
Yes if the snooper can snoop your connection you have problems. However
using our javascript the password is never in the connection. That can help
protect your other SPIP sites (on which of course you have the same
password, lazy you!).
Only safe bet is to use SSL.
True, you can add a better security layer with SSL, but SSL is not always
available.
-- Fil
> Only safe bet is to use SSL.
I should add a comment: the message you've seen is for the website
redactors and admins, not necessarily for the webmaster who has installed
the script. So regardless of the SLL or not, if they use javascript they'll
get a better security.
For the webmaster it would certainly be wise to add SSL to the ecrire/
directory. But that would be a piece of documentation to add to the spip.net
website, not a message on the login panel. If someone wants to contribute
such a documentation, you are most welcome! If patches are needed, we'll
gladly integrate them. But I must say that I have zero experience with SSL
and SPIP, and those who have have stayed silent 
-- Fil
Sometime on Jan 13, Fil assembled some asciibets to say:
Furthermore the hash opens a session that is tied to the IP address. If the
IP address used by the snooper is not the same, the hash will be renewed (no
ip spoofing 
anycase, I accept your explanation. The message may need to be changed
a bit, but I can't think of anything better, so will let it go at this
point.
Waiting to start using in once I get back to work tomorrow.
Philip
--
If the code and the comments disagree, then both are probably wrong.
-- Norm Schryer
Sometime on Jan 13, Fil assembled some asciibets to say:
gladly integrate them. But I must say that I have zero experience with SSL
and SPIP, and those who have have stayed silent
AFAIK (and I know nothing about SPIP), adding SSL to a web project
requires no changes to the project itself - provided the entire session
is over SSL. As long as the server and browser are both ssl aware, and
the protocol specified is https rather than http, we have SSL.
The problem creeps in if you try to do login over https and everything
else over http. There may be problems getting the cookie to be shared
between the two.
--
Unix: Some say the learning curve is steep, but you only have to climb it once.
-- Karl Lehenbauer