You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Kaare Rasmussen <ka...@webline.dk> on 2000/07/31 22:58:09 UTC
fdat blues
Once again I have a very strange problem.
In my order form I have a construction like this
[$ if (defined($fdat{order})) $]
say thanks for the order
[$ else $]
have a form where there is a submit button called "order".
[$endif$]
Problem is, it works only part of the time. Seems that if I change this file
(bestilling.epl), then %fdat turns up empty when I submit it through the order
button. Then I get the form again. If I try again from the top, still the same.
But if I insist and push the order button the second time (even the order is
empty), then fdat is coming back with its data. And then it works for the time
being; other orders can be made with no problem.
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2582
Howitzvej 75 �ben 14.00-18.00 Email: kar@webline.dk
2000 Frederiksberg L�rdag 11.00-17.00 Web: www.suse.dk
Re: Secure way of logging in
Posted by Kaare Rasmussen <ka...@webline.dk>.
Hi
> I thought about that right after I responded to the original message
> (it's amazing how insightful I get AFTER I've just pressed the send
> button). But it really depends on what your requirements are. The
Maybe I didn't explain myself very well, and maybe I'm mistaking something, but
my main problem is not the encryption, as I have a Verisign certificate for the
Apache server.
The problem is, how will I pass information from page a to b? Consider this:
Page a:
Username
Password
User enters these fields and they're validated. If OK, they are passed on to
page b - but how? Will a fdat entry with the username be secure enough? Or can
a person who knows the username fake it? I believe he can, but how can I make
this secure - I can't validate the password every time page b is called.
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2582
Howitzvej 75 �ben 14.00-18.00 Email: kar@webline.dk
2000 Frederiksberg L�rdag 11.00-17.00 Web: www.suse.dk
Re: Secure way of logging in
Posted by Rob Tanner <rt...@cheshire.onlinemac.com>.
--On 10/01/00 04:05:39 PM -0400 Ilia Lobsanov <il...@lobsanov.com> wrote:
> Rob, you shouldn't rely on JavaScript for this. And I don't see why
> you need cookies for that.
> Just use SSL if you don't want a sniffer to intercept the password.
>
> ilia.
>
I thought about that right after I responded to the original message
(it's amazing how insightful I get AFTER I've just pressed the send
button). But it really depends on what your requirements are. The
javascript algorythm does an excellent job, and it does the MD5 hash
correctly at the browser. Also, it works on any browser that does
javascript (no secure javascript or ssl signatures, etc, required). If
your concern is that the script could be sniffed, the MD5 hash
algorythm itself is widely available and security by obscurity is not a
good security model.
As far as ssl, there are several issues. Depending on your budget,
even the $125 for a Thawte certificate maybe too high. Also, on slow
links and older machines, SSL is more expensive timewise to run. Since
the original poster said nothing about securing the browser response
itself but only access to it (which is very common for commercial data
services although I don't know what kind of data Kaare Rasmussen in
concerned with in the original post). Also, I understand that
encryption is not legal in some Europen countries. I'm not sure which
ones and I have no idea what the rationale is, but MD5 password hashes
might conceivably skirt that issue.
On the plus side, in the US the old RSA patent became history last
month, either expiring on Sep 20 or valid through Sept 20. In any
event, it's now in the public domain and you can set up secure servers
without an RSA licensing issue. I don't know if there are other
international patents on the RSA algorythm or not, so I don't know
whether Europeans (the original post was from *.dk which is Denmark)
are so blessed or not.
-- Rob
_ _ _ _ _ _ _ _ _ _
/\_\_\_\_\ /\_\ /\_\_\_\_\_\
/\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR
/\/_/_/_/_/ /\_\ /\/_/ /\/_/
/\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin
\/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
Rob Tanner
McMinnville, Oregon
rtanner@cheshire.onlinemac.com
Re: Secure way of logging in
Posted by Ragnar Hakonarson <ra...@conquestnetwork.com>.
Take a look at Apche::TicketAccess. That module does the job..
On Sun, 1 Oct 2000, Ilia Lobsanov wrote:
> Rob, you shouldn't rely on JavaScript for this. And I don't see why you need
> cookies for that.
> Just use SSL if you don't want a sniffer to intercept the password.
>
> ilia.
>
> ----- Original Message -----
> From: "Rob Tanner" <rt...@cheshire.onlinemac.com>
> To: "Kaare Rasmussen" <ka...@webline.dk>; <em...@perl.apache.org>
> Sent: Sunday, October 01, 2000 12:20
> Subject: Re: Secure way of logging in
>
>
> > --On 10/01/00 01:05:10 PM +0200 Kaare Rasmussen <ka...@webline.dk> wrote:
> >
> > > Hi
> > >
> > > I'm looking for a way to log in to a database application. The
> > > database is PostgreSQL, and it would be nice if the solution would
> > > use the database for authentication.
> > >
> > > The webserver is apache. I could use htaccess, but I really need to
> > > know who's logging on, because the user is only allowed to see his
> > > own data from the database. Also, as stated above, it would be nice
> > > to use the database server so I only have to maintain information one
> > > place.
> > >
> > > I'm concerned about how to pass the login information to the database
> > > pages, without the possibility for others to fake this login
> > > information.
> > >
> >
> >
> > If you're willing to use cookies, have I got a method for you!!. For
> > basics on database authentication in conjunction with cookies, read
> > through chapter 6 of the eagle book. For making that authentication
> > interaction with the browser with the browser secure, what I do is an
> > MD5 challenge/response to the browser using a bit of javascript.
> >
> > First go to URL <http://pajhome.org.uk/crypt/md5> where you will find
> > the MD5 algorythm in javascript and copy it.
> >
> > The interaction with the browser is this: send a signon screen with two
> > embedded forms -- one that has the text input fields for username and
> > password, and one that has hidden fields. The hidden fields are used
> > to convey the username and the MD5 hash of the password. It's this
> > second form of hidden fields that gets submitted (otherwise you'd send
> > back the plain text password along with the MD5 hash and that kind of
> > defeats the purpose -- remember that in javascript you can't write to
> > or clear a password entry field)
> >
> > The other piece of this trick that make it work is the challenge. Also
> > in a hidden field, send some random data. I use a 64 byte random
> > string. In the javascript, first I make an MD5 hash of the password,
> > and then I make one long string of the user name, password hash and the
> > user plus the challenge string, and that's the hash that I send back to
> > the server along with the user name in plain text. At the server end,
> > when you authenticate the user, you simply perform the same process.
> > You will need a password file containing hashed passwords (the system
> > password file won't do -- those passwords are encrypted with UNIX
> > crypt), as well as a way of knowing what the challenge was you sent to
> > the browser. I send a serial number to the browser as well in a hidden
> > field and that allows me to lookup the challenge string in the
> > database. At that point, you simply do on your end what the javascript
> > did and if the end results match, the user is authenticated.
> >
> > What makes this secure is that a would-be sniffer never sees the plain
> > password -- it simply never hits the wire. Since the random challenge
> > is random (dah!), for all intents and purposes, without already knowing
> > the shared secret (i.e., the password), the response to the challenge
> > is random. Tus, the would-be sniffer/hacker still have to use the good
> > old brute force method, and since MD5 passwords are not limited to 8
> > bytes like UNIX crypt, brute force gets a lot harder (and even more so
> > if this hacker didn't catch the challenge as it came down the wire).
> >
> > -- Rob
> >
> >
> >
> > _ _ _ _ _ _ _ _ _ _
> > /\_\_\_\_\ /\_\ /\_\_\_\_\_\
> > /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
> > /\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR
> > /\/_/_/_/_/ /\_\ /\/_/ /\/_/
> > /\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin
> > \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
> >
> > Rob Tanner
> > McMinnville, Oregon
> > rtanner@onlinemac.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> > For additional commands, e-mail: embperl-help@perl.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
Re: Secure way of logging in
Posted by Ilia Lobsanov <il...@lobsanov.com>.
Rob, you shouldn't rely on JavaScript for this. And I don't see why you need
cookies for that.
Just use SSL if you don't want a sniffer to intercept the password.
ilia.
----- Original Message -----
From: "Rob Tanner" <rt...@cheshire.onlinemac.com>
To: "Kaare Rasmussen" <ka...@webline.dk>; <em...@perl.apache.org>
Sent: Sunday, October 01, 2000 12:20
Subject: Re: Secure way of logging in
> --On 10/01/00 01:05:10 PM +0200 Kaare Rasmussen <ka...@webline.dk> wrote:
>
> > Hi
> >
> > I'm looking for a way to log in to a database application. The
> > database is PostgreSQL, and it would be nice if the solution would
> > use the database for authentication.
> >
> > The webserver is apache. I could use htaccess, but I really need to
> > know who's logging on, because the user is only allowed to see his
> > own data from the database. Also, as stated above, it would be nice
> > to use the database server so I only have to maintain information one
> > place.
> >
> > I'm concerned about how to pass the login information to the database
> > pages, without the possibility for others to fake this login
> > information.
> >
>
>
> If you're willing to use cookies, have I got a method for you!!. For
> basics on database authentication in conjunction with cookies, read
> through chapter 6 of the eagle book. For making that authentication
> interaction with the browser with the browser secure, what I do is an
> MD5 challenge/response to the browser using a bit of javascript.
>
> First go to URL <http://pajhome.org.uk/crypt/md5> where you will find
> the MD5 algorythm in javascript and copy it.
>
> The interaction with the browser is this: send a signon screen with two
> embedded forms -- one that has the text input fields for username and
> password, and one that has hidden fields. The hidden fields are used
> to convey the username and the MD5 hash of the password. It's this
> second form of hidden fields that gets submitted (otherwise you'd send
> back the plain text password along with the MD5 hash and that kind of
> defeats the purpose -- remember that in javascript you can't write to
> or clear a password entry field)
>
> The other piece of this trick that make it work is the challenge. Also
> in a hidden field, send some random data. I use a 64 byte random
> string. In the javascript, first I make an MD5 hash of the password,
> and then I make one long string of the user name, password hash and the
> user plus the challenge string, and that's the hash that I send back to
> the server along with the user name in plain text. At the server end,
> when you authenticate the user, you simply perform the same process.
> You will need a password file containing hashed passwords (the system
> password file won't do -- those passwords are encrypted with UNIX
> crypt), as well as a way of knowing what the challenge was you sent to
> the browser. I send a serial number to the browser as well in a hidden
> field and that allows me to lookup the challenge string in the
> database. At that point, you simply do on your end what the javascript
> did and if the end results match, the user is authenticated.
>
> What makes this secure is that a would-be sniffer never sees the plain
> password -- it simply never hits the wire. Since the random challenge
> is random (dah!), for all intents and purposes, without already knowing
> the shared secret (i.e., the password), the response to the challenge
> is random. Tus, the would-be sniffer/hacker still have to use the good
> old brute force method, and since MD5 passwords are not limited to 8
> bytes like UNIX crypt, brute force gets a lot harder (and even more so
> if this hacker didn't catch the challenge as it came down the wire).
>
> -- Rob
>
>
>
> _ _ _ _ _ _ _ _ _ _
> /\_\_\_\_\ /\_\ /\_\_\_\_\_\
> /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
> /\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR
> /\/_/_/_/_/ /\_\ /\/_/ /\/_/
> /\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin
> \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
>
> Rob Tanner
> McMinnville, Oregon
> rtanner@onlinemac.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>
Re: Secure way of logging in
Posted by Rob Tanner <rt...@cheshire.onlinemac.com>.
--On 10/01/00 01:05:10 PM +0200 Kaare Rasmussen <ka...@webline.dk> wrote:
> Hi
>
> I'm looking for a way to log in to a database application. The
> database is PostgreSQL, and it would be nice if the solution would
> use the database for authentication.
>
> The webserver is apache. I could use htaccess, but I really need to
> know who's logging on, because the user is only allowed to see his
> own data from the database. Also, as stated above, it would be nice
> to use the database server so I only have to maintain information one
> place.
>
> I'm concerned about how to pass the login information to the database
> pages, without the possibility for others to fake this login
> information.
>
If you're willing to use cookies, have I got a method for you!!. For
basics on database authentication in conjunction with cookies, read
through chapter 6 of the eagle book. For making that authentication
interaction with the browser with the browser secure, what I do is an
MD5 challenge/response to the browser using a bit of javascript.
First go to URL <http://pajhome.org.uk/crypt/md5> where you will find
the MD5 algorythm in javascript and copy it.
The interaction with the browser is this: send a signon screen with two
embedded forms -- one that has the text input fields for username and
password, and one that has hidden fields. The hidden fields are used
to convey the username and the MD5 hash of the password. It's this
second form of hidden fields that gets submitted (otherwise you'd send
back the plain text password along with the MD5 hash and that kind of
defeats the purpose -- remember that in javascript you can't write to
or clear a password entry field)
The other piece of this trick that make it work is the challenge. Also
in a hidden field, send some random data. I use a 64 byte random
string. In the javascript, first I make an MD5 hash of the password,
and then I make one long string of the user name, password hash and the
user plus the challenge string, and that's the hash that I send back to
the server along with the user name in plain text. At the server end,
when you authenticate the user, you simply perform the same process.
You will need a password file containing hashed passwords (the system
password file won't do -- those passwords are encrypted with UNIX
crypt), as well as a way of knowing what the challenge was you sent to
the browser. I send a serial number to the browser as well in a hidden
field and that allows me to lookup the challenge string in the
database. At that point, you simply do on your end what the javascript
did and if the end results match, the user is authenticated.
What makes this secure is that a would-be sniffer never sees the plain
password -- it simply never hits the wire. Since the random challenge
is random (dah!), for all intents and purposes, without already knowing
the shared secret (i.e., the password), the response to the challenge
is random. Tus, the would-be sniffer/hacker still have to use the good
old brute force method, and since MD5 passwords are not limited to 8
bytes like UNIX crypt, brute force gets a lot harder (and even more so
if this hacker didn't catch the challenge as it came down the wire).
-- Rob
_ _ _ _ _ _ _ _ _ _
/\_\_\_\_\ /\_\ /\_\_\_\_\_\
/\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR
/\/_/_/_/_/ /\_\ /\/_/ /\/_/
/\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin
\/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
Rob Tanner
McMinnville, Oregon
rtanner@onlinemac.com
Secure way of logging in
Posted by Kaare Rasmussen <ka...@webline.dk>.
Hi
I'm looking for a way to log in to a database application. The database is
PostgreSQL, and it would be nice if the solution would use the database for
authentication.
The webserver is apache. I could use htaccess, but I really need to know
who's logging on, because the user is only allowed to see his own data from the
database. Also, as stated above, it would be nice to use the database server so
I only have to maintain information one place.
I'm concerned about how to pass the login information to the database pages,
without the possibility for others to fake this login information.
I hope someone has done this and will share
Regards,
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2582
Howitzvej 75 �ben 14.00-18.00 Email: kar@webline.dk
2000 Frederiksberg L�rdag 11.00-17.00 Web: www.suse.dk
Re: Continue on non-local page
Posted by Gerald Richter <ri...@ecos.de>.
Hi
>
> I need to go to another page. The page is on another system, so I cannot
> Execute the file.
>
> How do I unconditionally and without user intervention go to another page
on
> another site?
>
> I know I can use this
> [- $http_headers_out{'Location'} = "$fdat{newpage}" -]
>
> But this is a redirect, and the browser complains when I try to go from a
https
> to a normal http page. I would like to avoid this message, which will
confuse
> the user.
>
I don't know any other way.
The only thing would be if the original server acts as a proxy for the new
server, so it continues to be a https connection.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Continue on non-local page
Posted by Kaare Rasmussen <ka...@webline.dk>.
Hi
I need to go to another page. The page is on another system, so I cannot
Execute the file.
How do I unconditionally and without user intervention go to another page on
another site?
I know I can use this
[- $http_headers_out{'Location'} = "$fdat{newpage}" -]
But this is a redirect, and the browser complains when I try to go from a https
to a normal http page. I would like to avoid this message, which will confuse
the user.
Thanks in advance.
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2582
Howitzvej 75 �ben 14.00-18.00 Email: kar@webline.dk
2000 Frederiksberg L�rdag 11.00-17.00 Web: www.suse.dk
RE: Redirect w/data
Posted by Joe Lauer <jo...@rootlevel.com>.
I'm not quite sure why this is difficult?
[- $http_headers_out{'Location'} = $fdat{Errorpage} .
"?err=Error%20Occurred" -]
or you could just store the error in a session variable and then redirect.
-joe
______________________________________________________
joe lauer rootlevel
product developer 743 beaubien, suite 300
p.313.961.4407 x302 detroit, mi 48226
f.313.961.4568 www.rootlevel.com
-----Original Message-----
From: Kaare Rasmussen [mailto:kar@webline.dk]
Sent: Saturday, September 09, 2000 2:15 PM
To: embperl@perl.apache.org
Subject: Redirect w/data
Hi
I want to go to another page if some condition arises. I can do this
[- $http_headers_out{'Location'} = "$fdat{Errorpage}" -]
But what if I want to pass a variable? In fact I want the error page to
display
the content of a error variable.
Of course it is possible to construct a "GET" type situation if I change the
location, but I thought maybe there is an easier way to accomplish this.
The only other way I can think of is to have a <form action="[+
$fdat{Errorpage} +]" and then activate the form automatically by some means,
but
this seems silly somehow.
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Redirect w/data
Posted by Kaare Rasmussen <ka...@webline.dk>.
Hi
I want to go to another page if some condition arises. I can do this
[- $http_headers_out{'Location'} = "$fdat{Errorpage}" -]
But what if I want to pass a variable? In fact I want the error page to display
the content of a error variable.
Of course it is possible to construct a "GET" type situation if I change the
location, but I thought maybe there is an easier way to accomplish this.
The only other way I can think of is to have a <form action="[+
$fdat{Errorpage} +]" and then activate the form automatically by some means, but
this seems silly somehow.
Re: Foreach problem
Posted by Gerald Richter <ri...@ecos.de>.
>
> [Sat Aug 26 11:09:47 2000] [error] [831]ERR: 38: Line 33: Too few
arguments
> [Sat Aug 26 11:09:47 2000] [error] [831]ERR: 46: Line 33: Unclosed
command [$ foreach $] at end of file
>
> Line 33 is the start of the foreach loop.
>
> It only happens sometimes, and I really don't know why.
>
> I'm using 1.3b4 with the patch you sent me. Will 1.3b5 solve this problem?
>
I discovered this bug recently, it only occurs when you are using
EmbperlObject. It's solved in 1.3b6_dev, so you have to fetch Embperl from
the CVS (see perldoc CVS.pod)
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Foreach problem
Posted by Kaare Rasmussen <ka...@webline.dk>.
I have another problem with Embperl
This construct:
[$ foreach $prod @product $]
[$ if ($prod->{name}) $]
[+ $prod->{name}.'.value*'.$prod->{price}.' +' +]
[$ endif $]
[$ endforeach $]
gives me this error:
[Sat Aug 26 11:09:47 2000] [error] [831]ERR: 38: Line 33: Too few arguments
[Sat Aug 26 11:09:47 2000] [error] [831]ERR: 46: Line 33: Unclosed command [$ foreach $] at end of file
Line 33 is the start of the foreach loop.
It only happens sometimes, and I really don't know why.
I'm using 1.3b4 with the patch you sent me. Will 1.3b5 solve this problem?
Re: fdat blues
Posted by Gerald Richter <ri...@ecos.de>.
>
> No, it's not build as DSO; plain static. And mod_perl is, well look here:
> Apache/1.3.12 (Unix) mod_perl/1.24 configured -- resuming normal
operations
>
ok, so this is not the problem
> Could it be because there are a lot of fields in the form? I don't think
so,
> but just had to ask.
No, there is no limit
> Maybe, one never knows, I have an error somewhere in the HTML code. But
it's
> bewildering that it only happens when the .epl file is changed and thereby
> reloaded.
>
> Btw. it started when I installed 1.3b4. I installed this version to get
over
> the other strange problem I reported last time...
>
Is there any file upload in the form, i.e. is it multipart/formdata ?
Is it used inside EmbperlObject, or as a standalone page or called via
Execute?
If you are able to put together a small example, I try to reproduce it here
(or send me the whole page, if it works without special modules)
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
Re: fdat blues
Posted by Kaare Rasmussen <ka...@webline.dk>.
> I guess you already have mailed us your setup when we talk about
> EmbperlObject, but once again the question: Is mod_perl build as DSO? Which
> version of mod_perl? This problem is typical for a mod_perl version < 1.22,
> which is build as DSO and Embperl is loaded at server startup time.
No, it's not build as DSO; plain static. And mod_perl is, well look here:
Apache/1.3.12 (Unix) mod_perl/1.24 configured -- resuming normal operations
Could it be because there are a lot of fields in the form? I don't think so,
but just had to ask.
Maybe, one never knows, I have an error somewhere in the HTML code. But it's
bewildering that it only happens when the .epl file is changed and thereby
reloaded.
Btw. it started when I installed 1.3b4. I installed this version to get over
the other strange problem I reported last time...
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2582
Howitzvej 75 �ben 14.00-18.00 Email: kar@webline.dk
2000 Frederiksberg L�rdag 11.00-17.00 Web: www.suse.dk
Re: fdat blues
Posted by Gerald Richter <ri...@ecos.de>.
> > If you've already tried something like that, and it really is empty,
then
> > this is some sort of sinister, ugly persistence issue that I wouldn't
know
> > how to deal with ... I'm used to that :)
>
> It is really empty, or at least it doesn't contain the values I expect.
I've
> tried [+ "-> $fdat{order} <-" +] and other values than "order" that I
know
> should be there. But it's not there the first time around :-(
>
I guess you already have mailed us your setup when we talk about
EmbperlObject, but once again the question: Is mod_perl build as DSO? Which
version of mod_perl? This problem is typical for a mod_perl version < 1.22,
which is build as DSO and Embperl is loaded at server startup time.
Gerald
RE: fdat blues
Posted by Kaare Rasmussen <ka...@webline.dk>.
> If you've already tried something like that, and it really is empty, then
> this is some sort of sinister, ugly persistence issue that I wouldn't know
> how to deal with ... I'm used to that :)
It is really empty, or at least it doesn't contain the values I expect. I've
tried [+ "-> $fdat{order} <-" +] and other values than "order" that I know
should be there. But it's not there the first time around :-(
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2582
Howitzvej 75 �ben 14.00-18.00 Email: kar@webline.dk
2000 Frederiksberg L�rdag 11.00-17.00 Web: www.suse.dk
RE: fdat blues
Posted by Jack Cushman <jc...@davanita.com>.
I'm not experienced enough with embperl to instantly figure out the problem,
but my first debugging approach would be to print out all of %fdat and
figure out what it does contain. My personal preference to do that would be
use Data::Dumper;
print OUT Dumper %fdat;
If you've already tried something like that, and it really is empty, then
this is some sort of sinister, ugly persistence issue that I wouldn't know
how to deal with ... I'm used to that :)
--Jack
> -----Original Message-----
> From: Kaare Rasmussen [mailto:kar@webline.dk]
> Sent: Monday, July 31, 2000 4:58 PM
> To: Embperl@Perl. Apache. Org
> Subject: fdat blues
>
>
> Once again I have a very strange problem.
>
> In my order form I have a construction like this
>
> [$ if (defined($fdat{order})) $]
> say thanks for the order
> [$ else $]
> have a form where there is a submit button called "order".
> [$endif$]
>
> Problem is, it works only part of the time. Seems that if I
> change this file
> (bestilling.epl), then %fdat turns up empty when I submit it
> through the order
> button. Then I get the form again. If I try again from the top,
> still the same.
> But if I insist and push the order button the second time (even
> the order is
> empty), then fdat is coming back with its data. And then it works
> for the time
> being; other orders can be made with no problem.
>
> --
> Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
> Kaki Data tshirts, merchandize Fax: 3816 2582
> Howitzvej 75 Åben 14.00-18.00 Email: kar@webline.dk
> 2000 Frederiksberg Lørdag 11.00-17.00 Web: www.suse.dk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org