introducing a set of modules to create dynamic websites

[Marcel Greter]

ive you access to the developement site and if you like I 
could set nearly all code online within some days. But I think that I 
would need some more days to setup a "starter" package with some preset 
templates and users as otherwise you'll have some headaches setting up 
everything I think :-|

greetings, Marcel Greter

Re: Apache::Session

[Marcel Greter]

All the information that comes from the user-agent can be faked. So the 
session id is as insecure as any other identifier you get from the 
Browser. The only thing that could be used is the IP address, and as 
somebody said earlier, some ISPs and big company LANs may use different 
proxies for different requests (or use random routes for multiple output 
interfaces with some NAT gateway). Also the MAC address is not an 
option, any routing above layer 2? will loose the MAC address (if I'm 
not wrong).

But there is somehow a way to get it more secure. Basically a key/IP 
combination would be very secure, it's just not useable for all users. 
Therefore you need to allow multiple IPs for the same session key. After 
you see that a user from another IP request a session id, you prompt a 
login again, and after successfull login you allow both IPs to access 
this session ID. Every user then basically has to login for each IP he 
uses; but it could be done more tricky, so the whole subnet that those 
two IPs are in is allowed. The security risk would be, that any other 
user going though the same gateway can steal the session just by knowing 
the correct session id.

If the user is coming through proxies (as it IMHO normally is if you 
have several IPs for a session), you could even do more fancy stuff. 
Proxies should send an x-forwarded-for header, where they will add every 
IP that sent the request (can be multiple hosts). This way you could 
allow all those proxies for the session, but just for the same end IP 
(which should be the last IP from the x-forwarded-for field before any 
internal IP). Now we just have the security hole left, if someone is in 
control of those proxies, then he could steal the session from the 
original user.

IMHO this is really everything you can get out of it; you even get it a 
lot securer for proxied users. The only problem are LANs that use random 
NAT-Gateways, which IMHO aren't widely spread ??.

If you see anything more to make it secure, or if I'm totally wrong, I'm 
glad to hear !?

greets, Marcel Greter



--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Re: AW: AW: Use of uninitialized valued in concatenation....

[Marcel Greter]

-CUT--
my $val=$_||'NULL'; print qq($val);
-CUT--
 

This is not a very good solution. You would also catch the case where $_ 
is 0, which may should not happen. You would better do

foreach (@table_data) {
$_ = defined $_ ? $_ : "NULL";
print qq($_); # Here is line 42
}
Basically you also simply could use the warnings pragma within this sub :

no warnings "uninitialized";

greets, Marcel



--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Cookie Code

[Marcel Greter]

Tim Edwards wrote:

I'm sending 3 cookies. The first one goes properly. The second two get 
print to the screen. Same script run under normal perl works fine. 
Suggestions?
Just a suggestion, but are you sure that you don't print out the 
content-type header after sending the first cookie ? It somehow sounds 
like you do ...