Re: PerlDesk Help (Help With Database Host)

[Jordan Mclain]

Please let us know a little bit more about your setup.  i.e. have you
already installed mysql or are you running it on a remote server, what
OS are you running?

to connect to the mysql server from perl you will have to use the DBI
module, and the DBD:mysql module.

this is a link you may find useful:
http://www.perldoc.com/perl5.6.1/lib/DBI.html

if you are asking where mysql physically is on your machine; this
depends on what operating system you are running, where you installed
it, where your package manager installed it, or where it came default on
your system.

another link that will tell you more about the mysql server itself is:
http://mysql.org/

Jordan Mclain


On Tue, 2002-06-25 at 19:33, [EMAIL PROTECTED] wrote:
> I have installed PerlDesk onto my server.  Everything is fine, except that I 
> cannot located the database host.  Im not to good with MySQL and all, but if 
> someone could please direct me to right spot to find this, I would really 
> appreciate it.
> 
> Thanks in Advance




-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Renaming files

[learn perl]

use this:

you could use system commands if you are on winnt or w2k.

I normally just use

@filelist = `dir *.ext /b`;

foreach (@filelist){
@filename=split on the .
if last element of @filename is what you're looking for{
`rename $_ @filename[0].newext`
}
}

then you're done
hope this helps

Eric

On 25 Jun 2002, Felix Geerinckx wrote:

> on Tue, 25 Jun 2002 19:51:14 GMT, JoãO Paulo wrote:
>
> >
> > How can I quickly change the extension of a lot of files???
> >
> > something like   "file" into "file.something" ,JP.
>
> perldoc -f rename
> perldoc -f opendir
> perldoc -f readdir
>
> --
> felix
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Renaming files

[Felix Geerinckx]

on Tue, 25 Jun 2002 19:51:14 GMT, JoãO Paulo wrote:

> 
> How can I quickly change the extension of a lot of files???
> 
> something like   "file" into "file.something" ,JP.

perldoc -f rename
perldoc -f opendir
perldoc -f readdir

-- 
felix

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Fwd: passing variables in POST

[Bob Showalter]

> -Original Message-
> From: Ovid [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 3:34 PM
> To: Niko Gunadi; Beginners cgi
> Subject: Re: Fwd: passing variables in POST
> 
> 
> I was under the
> impression that Apache::Session required Apache.  I'm told 
> that this is not true, but I haven't
> researched it.  Anyone know about this?

Apache::Session doesn't require Apache. It doesn't
touch the web server at all, so you could use it in
non-web server situations.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Renaming files

[João Paulo]

How can I quickly change the extension of a lot of files???

something like   "file" into "file.something" ,JP.





_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Displaying Problems

[Kyle Babich]

Ok, I did like perldoc cgi said and changed it to this:

print start_html(
  -title => "IMAP.cc",
   -head  => Link( 
   { 
   -rel => "stylesheet",
   -type => "text/css",
   -href => "style.css",
   }
   ),
 -bgcolor => "\#FF"
   ),

It still won't work though.

- Original Message - 
From: "Bob Showalter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, June 25, 2002 1:23 PM
Subject: RE: Displaying Problems


> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, June 25, 2002 1:05 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Displaying Problems
> > 
> > 
> > Well, I still can't get my page to display.
> > 
> 
> Remove this line:
> 
>body( -bgcolor => "\#Ff" ),
> 
> It's emitting a  sequence. start_html opens the
> body tag and end_html closes it, so you don't need this. bgcolor
> should be passed to start_html.
> 
> Read the docs. perldoc CGI.
> 
> -- 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fwd: passing variables in POST

[Ovid]

--- Niko Gunadi <[EMAIL PROTECTED]> wrote:
> >thanks very much Ovid, it was very nice of you, but can you complete your
> >favour and describe how to implement Apache::Session, i mean, whats the use
> >of that module if i could generate a session id with md5?
> 
> you actually can use CGI::Session, the front end of Apache::Session.
> By using this module, you can easily save your variables to the session.
> you also can choose which storage for your session (from file to mysql).

When I wrote a lot of our in-house session handling code, we used IIS and I was under 
the
impression that Apache::Session required Apache.  I'm told that this is not true, but 
I haven't
researched it.  Anyone know about this?

Cheers,
Curtis "Ovid" Poe

=
"Ovid" on http://www.perlmonks.org/
Someone asked me how to count to 10 in Perl:
push@A,$_ for reverse q.e...q.n.;for(@A){$_=unpack(q|c|,$_);@a=split//;
shift@a;shift@a if $a[$[]eq$[;$_=join q||,@a};print $_,$/for reverse @A

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Displaying Problems

[Niko Gunadi]

On Tue, Jun 25, 2002 at 12:10:34PM -0600, [EMAIL PROTECTED] wrote:
>You know, I work with about 5 other perl programmers, most of which do use 
>CGI.pm, but none of
>them use it for anything other that gathering input from the web.  I have also 
>downloaded many
>packages from CPAN, I would say a majority of them use CGI.pm, but very rarely do I 
>see it used for
>anything but gathering data.

ah yes, I also use CGI.pm only to gather the input data as I'm afraid my
own method will break somewhere. :o
So, it's kinda of waste to use a big module for a simple task.
Instead of using CGI.pm to construct HTML, i'm using CGI::FastTemplate
which is more efficient and neater to use.

>I created a lib for receiving data from GET, POST or shell.  I will be releasing 
>it to CPAN
>soon, and expect to get this sort of thing quite a bit.  That is good, because I want 
>my lib to be
>very efficient and proper.  The reason I wrote my own is because I like my variables 
>in a easy to
>use structure:

I'm looking forward to this module to replace my CGI.pm :)

>With this structure, I can get to everything very easily.  It didn't make much 
>sense to use
>CGI.pm to gather the data, smush it into a data structure, only to loop through all 
>the data and
>shove it into another structure.

Yes, it's a pity

regards,
niko

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fwd: passing variables in POST

[Niko Gunadi]

>thanks very much Ovid, it was very nice of you, but can you complete your
>favour and describe how to implement Apache::Session, i mean, whats the use
>of that module if i could generate a session id with md5?

you actually can use CGI::Session, the front end of Apache::Session.
By using this module, you can easily save your variables to the session.
you also can choose which storage for your session (from file to mysql).

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Displaying Problems

[perl-dvd]

Bob,
That's interesting.
You know, I work with about 5 other perl programmers, most of which do use CGI.pm, 
but none of
them use it for anything other that gathering input from the web.  I have also 
downloaded many
packages from CPAN, I would say a majority of them use CGI.pm, but very rarely do I 
see it used for
anything but gathering data.
I'm not suggesting we shouldn't follow the standard.  I am suggesting that this 
particular
standard will never be enforced, because if it was, I'd be willing to bet, it would 
break a great
percentage of perl scripts out there.  But yes, I agree with you that we should all 
try to follow
the specs pretty closely.
Anyway, personally, I don't use CGI.pm at all, and it would be a real shame if I 
began including
the whole thing just for that.  It would just seem smarter for me to begin using this  
print
"Content-type: text/html${CRLF}${CRLF}";  instead.
I created a lib for receiving data from GET, POST or shell.  I will be releasing 
it to CPAN
soon, and expect to get this sort of thing quite a bit.  That is good, because I want 
my lib to be
very efficient and proper.  The reason I wrote my own is because I like my variables 
in a easy to
use structure:
%hash = (
'a_name' => 'value',   # for single name value pairs
'b_name' => ["multiple", "values", "for", "this"],   # for single name muli-value 
sets
'c_name' => {
 'original_name' => 'filename.jpg',
 'size' => '23554',
 'location' => 
'/tmp/fileupload/tmpfile-10028983-88.57.192.3-2783-298374-927837'
 } # for files
);
With this structure, I can get to everything very easily.  It didn't make much 
sense to use
CGI.pm to gather the data, smush it into a data structure, only to loop through all 
the data and
shove it into another structure.
I'm sure I'll get lots of hate mail from CGI.pm die hard's, but my other choice is 
to just not
post this at all.  What I hope for is several people telling me how to make it 
slightly more
efficient or compatible with other OS's (you see I've only had opportunity to test it 
on Linux and
Win2000, though I've been testing it on Linux for about 2 1/2 years).
Its pretty hard to make it more simple than:
use Form;
my %input = Form();

David



- Original Message -
From: "Bob Showalter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, June 25, 2002 11:12 AM
Subject: RE: Displaying Problems


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 12:47 PM
> To: Bob Showalter; [EMAIL PROTECTED]
> Subject: Re: Displaying Problems
>
>
> Ok, so here's the deal:
>
> "Some HTTP/1.0 software has interpreted a Content-Type header
> without charset parameter incorrectly
> to mean "recipient should guess." Senders wishing to defeat
> this behavior MAY include a charset
> parameter even when the charset is ISO-8859-1 and SHOULD do
> so when it is known that it will not
> confuse the recipient."
>
> By the way, I did not upper case the MAY and SHOULD, those
> were that way in the doc which means they
> were trying to emphasize them.  I'd have to say that MAY
> doesn't suggest that it is a requirement
> for the content-type to work properly.

This is the relevant paragraph from 2.2 that I was going for:

   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
   protocol elements except the entity-body (see appendix 19.3 for
   tolerant applications). The end-of-line marker within an entity-body
   is defined by its associated media type, as described in section 3.7.

Appendix 19.3 (Tolerant Applications) says, in part:

   The line terminator for message-header fields is the sequence CRLF.
   However, we recommend that applications, when parsing such headers,
   recognize a single LF as a line terminator and ignore the leading CR.

But, section 3.7 says:

   When in canonical form, media subtypes of the "text" type use CRLF as
   the text line break. HTTP relaxes this requirement and allows the
   transport of text media with plain CR or LF alone representing a line
   break when it is done consistently for an entire entity-body. HTTP
   applications MUST accept CRLF, bare CR, and bare LF as being
   representative of a line break in text media received via HTTP. In
   addition, if the text is represented in a character set that does not
   use octets 13 and 10 for CR and LF respectively, as is the case for
   some multi-byte character sets, HTTP allows the use of whatever octet
   sequences are defined by that character set to represent the
   equivalent of CR and LF for line breaks. This flexibility regarding
   line breaks applies only to text media in the entity-body; a bare CR
   or LF MUST NOT be substituted for CRLF within any of the HTTP control
   structures (such as header fields and multipart boundaries).

Note especially the last sentence.

A nit-pick, to be sure. But "little things" like this cause prog

Using CGI.pm [WAS Re: Displaying Problems]

[John Brooking]

I tend to always use CGI.pm to get the parameters, but
I may or may not use it to output HTML. If it's simple
HTML, I will, because it's easier and safer, but if
it's complicated, like a lot of JavaScript in the
header, or for most form input controls, I just use
print statements, either normal ones for one or two
lines, or the 

Re: Fwd: passing variables in POST

[Hytham Shehab]

>   my $md5= new Digest::MD5;
>   my $remote = $ENV{ REMOTE_ADDR } . $ENV{ REMOTE_PORT } . $self->{
_rand };
>   my $id = $md5->md5_base64( time, $$, $remote );
>   $id=~ tr|+/=|-_.|; # Make non-word characters URL-friendly
>
> The "Make ... URL-friendly" part is in case I need to embed the session ID
in a URL.
>
> As for the "_rand" on the end, that's a random number that I tack onto the
end to ensure unique
> ids are generated.
>
thanks very much Ovid, it was very nice of you, but can you complete your
favour and describe how to implement Apache::Session, i mean, whats the use
of that module if i could generate a session id with md5?



btw, whats the %self is?

--
Hytham Shehab


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Displaying Problems

[Brian]

Hmm, a perl syntax checks out, but the script seemingly dies when ran?  One 
thing I've found and don't yet fully understand, is it seems like when 
importing other modules the perl check doesn't seem to catch undeclared subs 
despite use strict- any ideas?

Either way, I digress- basic things but, A) I'd check the webserver logs- 
usually theres some info in there at least of what happened, B) and I'd try 
running the script via the terminal- it'll require a little bit of 
modification to it (aka, hardcode $c to a value for testing), but I've used 
it time and time again to find exactly how and where a script that has passed 
syntax checking is doing something that leads to its death...

On a seperate note- I'd tend to agree with the other poster- while the CGI 
module is indispensible, it seems like some parts of it are overkill- a base 
example would be existance of a paragraph method- a method that returns a 
''.
Either way, good luck with it.
~Brian


On Monday 24 June 2002 15:09, Kyle Babich wrote
> For the following the syntax is correct but when I try to open it 
> nothing displays, what should I change?
>
> #!/usr/bin/perl -wT
> use strict;
> use CGI::Pretty qw/ :standard /;
> $CGI::DISABLE_UPLOADS = 1;
> $CGI::POST_MAX = 512 * 1024;
>
> print header ( "text/html" );
>
> my $date = localtime;
>
> my $c = param('c');
> my $content = "c";
>
> if ($c eq "h") {
>$content = qq{\n};
> } elsif ($c eq "eh") {
>$content = qq{\n};
> } elsif ($c eq "hd") {
>$content = qq{\n};
> } elsif ($c eq "p") {
>$content = qq{\n};
> } elsif ($c eq "c") {
>$content = qq{\n};
> } elsif ($c eq "su") {
>$content = qq{\n};
> }
>
> my @nav = ("Home","E-Mail Hosting","Help
> Desk","Policies","Contact","Signup");
>
> my @loc = ("index.cgi?c=h","index.cgi?c=eh","index.cgi?c=hd","index.cgi?
> c=p",
>"index.cgi?c=c","index.cgi?c=su");
>
> print start_html(
>   -title => "IMAP.cc E-Mail Hosting",
>-head  => Link(
>{
>-rel => "stylesheet",
>-type => "text/css",
>-href => "style.css"
>}
>),
>),
>body( -bgcolor => "\#FF" ),
>table({
>-width => "95\%",
>-cellspacing => "0",
>-cellpadding => "0",
>-border => "1",
>-bordercolor => "\#00"},
>tbody(
>   Tr(
>   td( {-width => "100\%"},
>table({
>   -width => "100\%",
>   -cellspacing => "0",
>   -cellpadding => "1",
>   -border => "1",
>   -bordercolor => "\#00"
>   -align => "center"},
>tbody(
>   Tr(
>   td( {-width => "100\%",
>   -bgcolor => "\#00",
>   -align => "center"},
>Font({
>   -face => "Verdana, Arial, Times New Roman",
>   -size => "4",
>   -color => "\#FF"},
>   "IMAP.cc"
>   )
>   ),),),),),),),),
> end_html


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Displaying Problems

[Bob Showalter]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 1:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Displaying Problems
> 
> 
> Well, I still can't get my page to display.
> 

Remove this line:

   body( -bgcolor => "\#Ff" ),

It's emitting a  sequence. start_html opens the
body tag and end_html closes it, so you don't need this. bgcolor
should be passed to start_html.

Read the docs. perldoc CGI.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: param problem

[Theuerkorn Johannes]

Hi Joe,

just hab the same Problems with your Script as with cgi::param,...
Ok, I just played around a little bit, checked some books and came to this solution:

our %values;

sub parse_form {

my ($ENV,$daten,@fields,$name,$value);  
if ($ENV{'REQUEST_METHOD'} eq 'GET')
{$daten = $ENV{'QUERY_STRING'}
}
else
{read(STDIN,$daten,$ENV{'CONTENT_LENGTH'});
}

@fields = split (/&/,$daten);
foreach (@fields){
($name, $value) = split(/=/, $_);
$values {$name} = $value;
}
 } # End sub parse_form

Only thing I want to change now is the access to the Values. Seems to be nice like you 
do it, but I still couldn´t follow...
So I have to recall it like print $values{seriennummer};
Working on it... :-)

Greets Johannes

> -Ursprüngliche Nachricht-
> Von:  David vd Geer Inhuur tbv IPlib [SMTP:[EMAIL PROTECTED]]
> Gesendet am:  Dienstag, 25. Juni 2002 17:47
> An:   [EMAIL PROTECTED]
> Betreff:  param problem
> 
> 
> Johan,
> 
> Somethings are going wrong here.
> Indeed the "our" should make the var global.
> 
> Looking at your header it's obvious you use : name=value&name2=value2
> 
> When you print $header, you will see that the first "?" is not shown.
> What I did in my script was building my header like this :
> 
> name1=value1?name2=value2? ...
> 
> So what you have got to do right now is :
> 
> @pairs = split(/\&/, $head); # split vars using & as delimitor
> 
> You see, change the question mark into a ampensant(&). Now you will get you scalars
> just like you used to.
> 
> our ${$name} = $value;
> 
> Does nothing else then :
> 
> our $serien = "10/rd30";
> 
> It's just that it does it automated, so you can use : print "Serienumber: $serien";
> To print it. give it a try within the sub-routine and outside. Just to make sure the
> our works.
> 
> 
> Regs David
> > 
> > Our?! Never heard this bevore,... as you probably can think now i´am new to 
>perl,.. :-) 
> > 
> > So I guess our is the opposite to my? My is available only in the routine it is 
>defined in (and the called subroutines) and our is also available for the main script 
>or any other colling part even if it is defined in a subroutine?
> > 
> > Still it´s not clear to me how to access my values,... :-)
> > 
> > If i pass the parameters ?parameter1=value1¶meter2=value2, i have to access 
>the parametervalues like $$parameter1 and $$parameter2 alright?
> > 
> > Johannes
> > 
> > > -Ursprüngliche Nachricht-
> > > Von:  David vd Geer Inhuur tbv IPlib [SMTP:[EMAIL PROTECTED]]
> > > Gesendet am:  Dienstag, 25. Juni 2002 17:26
> > > An:   [EMAIL PROTECTED]
> > > Betreff:  Re: AW: AW: AW: AW: param problem
> > > 
> > > 
> > > Make Sure you do the "our ${$name} = $value;"
> > > 
> > > this will make the $name available throught the script.
> > > The rest I would pre-define in the sub-routine :
> > > 
> > > sub parse_form {
> > > 
> > >   my ($buffer, $value, $name, .. ... .);
> > >   ...
> > >   ..
> > >   our ${$name} = $value;
> > > 
> > > }
> > > 
> > > Good Luck.
> > > 
> > > Regs David
> > > -
> > > > Ok, got some problems using strict but thats OK.one last Thing for today: 
>where do i have to call the sub 
> > > > and how do I access the parameters later in the script?
> > > > 
> > > > greetings Johannes usually one named me Joe to,...
> > > > > -Urspr> üngliche Nachricht-
> > > > > Von:  David vd Geer Inhuur tbv IPlib [SMTP:[EMAIL PROTECTED]]
> > > > > Gesendet am:  Dienstag, 25. Juni 2002 17:03
> > > > > An:   [EMAIL PROTECTED]
> > > > > Betreff:  Re: AW: AW: AW: param problem
> > > > > 
> > > > > 
> > > > > Yep, you'dd better do.
> > > > > This is always the first routine I load before I start to do anything.
> > > > > 
> > > > > Regs David
> > > > > > 
> > > > > > OK, I´m going to try it then,...
> > > > > > Just thought one should know what to put in a script,... :-) But aren> ´t 
>we all just Zombies,... :-)
> > > > > > Guess i have to do that in the beginning of the script?
> > > > > > 
> > > > > > Johannes
> > > > > > > -Ursprüngliche Nachricht-
> > > > > > > Von:  David vd Geer Inhuur tbv IPlib 
>[SMTP:[EMAIL PROTECTED]]
> > > > > > > Gesendet am:  Dienstag, 25. Juni 2002 16:30
> > > > > > > An:   [EMAIL PROTECTED]; 
>[EMAIL PROTECTED]
> > > > > > > Cc:   [EMAIL PROTECTED]
> > > > > > > Betreff:  Re: AW: AW: param problem
> > > > > > > 
> > > > > > > 
> > > > > > > Hi Johan,
> > > > > > > 
> > > > > > > Let's tell you a secret.
> > > > > > > I don't know what it means as well :)
> > > > > > > Well some part then. This is just typicaly something I always re-use and
> > > > > > > actualy never had the time to re-look at it.
> > > > > > > 
> > > > > > > Don't worry about the length by the way. Just give it a try, it never 
>failed for
> > > > > > > me. And maybe you might become one of the zombies (just like me), that 
>now and
> > > > > > > tha

RE: Displaying Problems

[Bob Showalter]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 12:47 PM
> To: Bob Showalter; [EMAIL PROTECTED]
> Subject: Re: Displaying Problems
> 
> 
> Ok, so here's the deal:
> 
> "Some HTTP/1.0 software has interpreted a Content-Type header 
> without charset parameter incorrectly
> to mean "recipient should guess." Senders wishing to defeat 
> this behavior MAY include a charset
> parameter even when the charset is ISO-8859-1 and SHOULD do 
> so when it is known that it will not
> confuse the recipient."
> 
> By the way, I did not upper case the MAY and SHOULD, those 
> were that way in the doc which means they
> were trying to emphasize them.  I'd have to say that MAY 
> doesn't suggest that it is a requirement
> for the content-type to work properly.

This is the relevant paragraph from 2.2 that I was going for:

   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
   protocol elements except the entity-body (see appendix 19.3 for
   tolerant applications). The end-of-line marker within an entity-body
   is defined by its associated media type, as described in section 3.7.

Appendix 19.3 (Tolerant Applications) says, in part:

   The line terminator for message-header fields is the sequence CRLF.
   However, we recommend that applications, when parsing such headers,
   recognize a single LF as a line terminator and ignore the leading CR.

But, section 3.7 says:

   When in canonical form, media subtypes of the "text" type use CRLF as
   the text line break. HTTP relaxes this requirement and allows the
   transport of text media with plain CR or LF alone representing a line
   break when it is done consistently for an entire entity-body. HTTP
   applications MUST accept CRLF, bare CR, and bare LF as being
   representative of a line break in text media received via HTTP. In
   addition, if the text is represented in a character set that does not
   use octets 13 and 10 for CR and LF respectively, as is the case for
   some multi-byte character sets, HTTP allows the use of whatever octet
   sequences are defined by that character set to represent the
   equivalent of CR and LF for line breaks. This flexibility regarding
   line breaks applies only to text media in the entity-body; a bare CR
   or LF MUST NOT be substituted for CRLF within any of the HTTP control
   structures (such as header fields and multipart boundaries).

Note especially the last sentence.

A nit-pick, to be sure. But "little things" like this cause programs
to break all the time. Like I said, most (maybe all?) clients will 
accept what you wrote, but why not stick to the standard? Or, save
all the trouble of grovelling through the RFC's and:

   print $q->header;

Cheers.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Displaying Problems

[kb]

Well, I still can't get my page to display.

Quoting [EMAIL PROTECTED]:

> Ok, so here's the deal:
> 
> "Some HTTP/1.0 software has interpreted a Content-Type header without charset
> parameter incorrectly
> to mean "recipient should guess." Senders wishing to defeat this behavior MAY
> include a charset
> parameter even when the charset is ISO-8859-1 and SHOULD do so when it is
> known that it will not
> confuse the recipient."
> 
> By the way, I did not upper case the MAY and SHOULD, those were that way in
> the doc which means they
> were trying to emphasize them.  I'd have to say that MAY doesn't suggest that
> it is a requirement
> for the content-type to work properly.
> 
> David
> 
> 
> 
> - Original Message -
> From: "Bob Showalter" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Tuesday, June 25, 2002 9:33 AM
> Subject: RE: Displaying Problems
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, June 25, 2002 11:12 AM
> > To: Bob Showalter; [EMAIL PROTECTED]
> > Subject: Re: Displaying Problems
> >
> >
> > Bob,
> >
> > ...
> > So what exactly is the RFC2616 compliant content type?
> 
> cf. ftp://ftp.isi.edu/in-notes/rfc2616.txt, section 2.2
> 
> >
> > You know its funny, but it seems that so many who stick up
> > for CGI.pm so strongly are quick to say
> > that CGI.pm is doing things right and that it does them
> > better, but they seem to purposely avoid
> > giving the actual solution.
> 
> See above.
> 
> >
> > It seems to me that our way of life (freedom and prosperity)
> > came about from people thinking for
> > them selves and from innovation, learning and continued drive
> > to improve what was given us.
> > I do a little system admin on the side, and I've come to find
> > that learning the actual conf files is
> > such a boon over simply using the GUI app.  So much
> > understanding has come and it takes me to a more
> > advanced level.  Many times I can discover a problem, or have
> > understanding of the underlying
> > problem when coming across things I don't expect.  In my mind
> > programming is the same.  I want to
> > know what's going on, so I can make a wise and educated
> > decision of how to approach it.
> 
> CGI.pm--a threat to our way of life! Down with the troglodytes! :)
> 
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> -- 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 




-
This mail sent through IMP: http://horde.org/imp/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Displaying Problems

[perl-dvd]

Ok, so here's the deal:

"Some HTTP/1.0 software has interpreted a Content-Type header without charset 
parameter incorrectly
to mean "recipient should guess." Senders wishing to defeat this behavior MAY include 
a charset
parameter even when the charset is ISO-8859-1 and SHOULD do so when it is known that 
it will not
confuse the recipient."

By the way, I did not upper case the MAY and SHOULD, those were that way in the doc 
which means they
were trying to emphasize them.  I'd have to say that MAY doesn't suggest that it is a 
requirement
for the content-type to work properly.

David



- Original Message -
From: "Bob Showalter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, June 25, 2002 9:33 AM
Subject: RE: Displaying Problems


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 11:12 AM
> To: Bob Showalter; [EMAIL PROTECTED]
> Subject: Re: Displaying Problems
>
>
> Bob,
>
> ...
> So what exactly is the RFC2616 compliant content type?

cf. ftp://ftp.isi.edu/in-notes/rfc2616.txt, section 2.2

>
> You know its funny, but it seems that so many who stick up
> for CGI.pm so strongly are quick to say
> that CGI.pm is doing things right and that it does them
> better, but they seem to purposely avoid
> giving the actual solution.

See above.

>
> It seems to me that our way of life (freedom and prosperity)
> came about from people thinking for
> them selves and from innovation, learning and continued drive
> to improve what was given us.
> I do a little system admin on the side, and I've come to find
> that learning the actual conf files is
> such a boon over simply using the GUI app.  So much
> understanding has come and it takes me to a more
> advanced level.  Many times I can discover a problem, or have
> understanding of the underlying
> problem when coming across things I don't expect.  In my mind
> programming is the same.  I want to
> know what's going on, so I can make a wise and educated
> decision of how to approach it.

CGI.pm--a threat to our way of life! Down with the troglodytes! :)

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: passing variables in POST

[David T-G]

Marty, et al --

...and then Marty Landman said...
% 
% At 05:47 AM 6/25/02 -0700, John Brooking wrote:
% 
...
% >  But wait, there's more! Even if your script *did*
% >check the referer, that's no protection either! An
% >experienced programmer can easily use Perl's LWP
% >module or its equivalent in some other language to
% >make the request with a faked referer variable. So
% >really, POST variables are no more secure than GET
% >variables, it just takes a little more doing to fake
% >them.
% 
% Didn't realize this. What exactly is the right procedure then to safeguard 
% scripts such as formmailers from being hijacked?
% 
% >   By the way, I'm still not a security expert, so
% >don't take my word as the final one either!
% 
% Me either, eager to learn and improve myself.

It takes being hacked a lot to finally be able to call yourself an
expert :-)


% 
% Marty
% 
% --
% SIMPL WebSite Creation: http://face2interface.com/Home/Demo.shtml


TIA & HAND

:-D
-- 
David T-G  * It's easier to fight for one's principles
(play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg!




msg05558/pgp0.pgp
Description: PGP signature

Re: passing variables in POST

[John Brooking]

--- Marty Landman <[EMAIL PROTECTED]> wrote:
> > ...
> >check the referer, that's no protection either! An
> >experienced programmer can easily use Perl's LWP
> >module or its equivalent in some other language to
> >make the request with a faked referer variable. So
> >really, POST variables are no more secure than GET
> >variables, it just takes a little more doing to
> fake
> >them.
> 
> Didn't realize this. What exactly is the right
> procedure then to safeguard 
> scripts such as formmailers from being hijacked?

--- Marty Landman <[EMAIL PROTECTED]> wrote:
> Didn't realize this. What exactly is the right
> procedure then to safeguard 
> scripts such as formmailers from being hijacked?

Not sure if there is a way. We had a big discussion a
few weeks back about a certain classic form mailer
script  (and let's not resurrect it please!), and from
what I could tell, one of the improvements made by the
recommended replacement was that it put a limit on the
number of simultaneous target addresses, to prevent
spamming. This makes me think there's really no way to
enforce who is calling you. But I don't know that for
sure.

Ovid's point a few messages ago that you shouldn't
trust anything outside your own box also seems
relevant.

Anyone with more security experience want to take a
crack at this? (Where's that guy who flamed me last
year when I need him?  :-)

- John


=
"Now it's over, I'm dead, and I haven't done anything that I want; or, I'm still 
alive, and there's nothing I want to do." - They Might Be Giants, http://www.tmbg.com

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Displaying Problems

[perl-dvd]

Bob,

> CGI.pm--a threat to our way of life! Down with the troglodytes! :)
Well, not exactly my point, but ok :)   Just kidding
I just think there are too many who close their minds to anything but CGI.pm, 
including potentially
more efficient customized solutions.

David


- Original Message -
From: "Bob Showalter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, June 25, 2002 9:33 AM
Subject: RE: Displaying Problems


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 11:12 AM
> To: Bob Showalter; [EMAIL PROTECTED]
> Subject: Re: Displaying Problems
>
>
> Bob,
>
> ...
> So what exactly is the RFC2616 compliant content type?

cf. ftp://ftp.isi.edu/in-notes/rfc2616.txt, section 2.2

>
> You know its funny, but it seems that so many who stick up
> for CGI.pm so strongly are quick to say
> that CGI.pm is doing things right and that it does them
> better, but they seem to purposely avoid
> giving the actual solution.

See above.

>
> It seems to me that our way of life (freedom and prosperity)
> came about from people thinking for
> them selves and from innovation, learning and continued drive
> to improve what was given us.
> I do a little system admin on the side, and I've come to find
> that learning the actual conf files is
> such a boon over simply using the GUI app.  So much
> understanding has come and it takes me to a more
> advanced level.  Many times I can discover a problem, or have
> understanding of the underlying
> problem when coming across things I don't expect.  In my mind
> programming is the same.  I want to
> know what's going on, so I can make a wise and educated
> decision of how to approach it.

CGI.pm--a threat to our way of life! Down with the troglodytes! :)



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: passing variables in POST

[Ovid]

--- John Brooking <[EMAIL PROTECTED]> wrote:
> So
> really, POST variables are no more secure than GET
> variables, it just takes a little more doing to fake
> them.

Side note (without really reading the rest of the thread :)

The reason that many people think POST is more secure than GET is because POST data 
does not show
up on the Web server's access logs.  Thus, if someone is submitting password 
information via GET,
even over SSL, anyone with access to the access logs can see the password.  Here's how 
this might
look on Apache:

127.0.0.1 - - [31/Oct/2001:08:52:14 -0800] "GET 
/cgi-bin/test.cgi?name=Ovid&password=youwish
HTTP/1.1" 200 633

Here's a typical post request, one which *did* have data sent:

127.0.0.1 - - [20/Nov/2001:17:07:43 -0800] "POST /cgi-bin/test.cgi HTTP/1.1" 200 462

Since POST data is read from STDIN, it's typically not ever stored on disk unless the 
programmer
handles that.

Cheers,
Curtis "Ovid" Poe

=
"Ovid" on http://www.perlmonks.org/
Someone asked me how to count to 10 in Perl:
push@A,$_ for reverse q.e...q.n.;for(@A){$_=unpack(q|c|,$_);@a=split//;
shift@a;shift@a if $a[$[]eq$[;$_=join q||,@a};print $_,$/for reverse @A

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fwd: passing variables in POST

[Ovid]

--- [EMAIL PROTECTED] wrote:
> what about a sesion id based on their IP? or soem relevent info like that?

Here's how I create session IDs:

  my $md5= new Digest::MD5;
  my $remote = $ENV{ REMOTE_ADDR } . $ENV{ REMOTE_PORT } . $self->{ _rand };
  my $id = $md5->md5_base64( time, $$, $remote );
  $id=~ tr|+/=|-_.|; # Make non-word characters URL-friendly
 
The "Make ... URL-friendly" part is in case I need to embed the session ID in a URL.  

As for the "_rand" on the end, that's a random number that I tack onto the end to 
ensure unique
ids are generated.

> may be a stupid way to do it.. but i track the "count" of how many users are 
> currently at my site by their IP/timestamp that is saved for 5 min. if 
> someone accesses the web site 5+ min after a timestamp those IP's are deleted 
> and the list is updated to only include IP hits within the last 5 min. so in 
> short it keeps a "somewhat crappy" count of how many are currently viewing 
> the site...

Actually, you don't want to track their IP.  Many people will connect with a different 
IP every
time, if they are on AOL or are have some corporate proxy server that assigns new IPs. 
 I just use
the IP for an initial seed.  If you recompute with the assumption that the IP is 
static, many
people will be kicked off.
 
As for how to enforce the 5 minute limit, I save a timestamp in a database and compare 
everything
to that.  Remember, when dealing with security, you can't trust *anything* outside of 
your box.

Cheers,
Curtis "Ovid" Poe

=
"Ovid" on http://www.perlmonks.org/
Someone asked me how to count to 10 in Perl:
push@A,$_ for reverse q.e...q.n.;for(@A){$_=unpack(q|c|,$_);@a=split//;
shift@a;shift@a if $a[$[]eq$[;$_=join q||,@a};print $_,$/for reverse @A

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Displaying Problems

[Bob Showalter]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 11:12 AM
> To: Bob Showalter; [EMAIL PROTECTED]
> Subject: Re: Displaying Problems
> 
> 
> Bob,
> 
> ...
> So what exactly is the RFC2616 compliant content type?

cf. ftp://ftp.isi.edu/in-notes/rfc2616.txt, section 2.2

> 
> You know its funny, but it seems that so many who stick up 
> for CGI.pm so strongly are quick to say
> that CGI.pm is doing things right and that it does them 
> better, but they seem to purposely avoid
> giving the actual solution.

See above.

> 
> It seems to me that our way of life (freedom and prosperity) 
> came about from people thinking for
> them selves and from innovation, learning and continued drive 
> to improve what was given us.
> I do a little system admin on the side, and I've come to find 
> that learning the actual conf files is
> such a boon over simply using the GUI app.  So much 
> understanding has come and it takes me to a more
> advanced level.  Many times I can discover a problem, or have 
> understanding of the underlying
> problem when coming across things I don't expect.  In my mind 
> programming is the same.  I want to
> know what's going on, so I can make a wise and educated 
> decision of how to approach it.

CGI.pm--a threat to our way of life! Down with the troglodytes! :)

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Displaying Problems

[perl-dvd]

Bob,

> I fail to see how writing code with errors is somehow CGI.pm's fault
No its not.  But I'll tell you one thing, people who depend so heavily on CGI.pm 
generally have a
good understanding of how to use CGI.pm, but have less understanding of what is really 
going on.  Me
personally, I want to know what's really happening.  And once I get to that point, not 
only can I
become more efficient, but I can make better decisions for my own application.  You 
see, just like
sterio-typing can frequently be incorrect (because it uses blanket statements), CGI.pm 
is not the
most efficient and for that matter appropriate for many situations.

> Except that that's not RFC2616-compliant, while CGI.pm's output is
So what exactly is the RFC2616 compliant content type?

You know its funny, but it seems that so many who stick up for CGI.pm so strongly are 
quick to say
that CGI.pm is doing things right and that it does them better, but they seem to 
purposely avoid
giving the actual solution.

It seems to me that our way of life (freedom and prosperity) came about from people 
thinking for
them selves and from innovation, learning and continued drive to improve what was 
given us.
I do a little system admin on the side, and I've come to find that learning the actual 
conf files is
such a boon over simply using the GUI app.  So much understanding has come and it 
takes me to a more
advanced level.  Many times I can discover a problem, or have understanding of the 
underlying
problem when coming across things I don't expect.  In my mind programming is the same. 
 I want to
know what's going on, so I can make a wise and educated decision of how to approach it.

David


- Original Message -
From: "Bob Showalter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, June 25, 2002 8:39 AM
Subject: RE: Displaying Problems


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 10:26 AM
> To: Kyle Babich; [EMAIL PROTECTED]
> Subject: Re: Displaying Problems
>
>
> Kyle,
> Well, I'd start by printing an actual content type
> instead of depending on CGI.pm for that:
> ---
> print "content-type: text/html\n\n";

Except that that's not RFC2616-compliant, while CGI.pm's output is.

Most browsers will accept this, but you still shouldn't generate it.

> ...
> Then I would HIGHLY recommend that you not depend on
> CGI.pm so heavily.  I would suggest you
> print out your own html, then you can see exactly what it is
> displaying and know what to change.

I fail to see how writing code with errors is somehow
CGI.pm's fault.



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Displaying Problems

[Bob Showalter]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 10:26 AM
> To: Kyle Babich; [EMAIL PROTECTED]
> Subject: Re: Displaying Problems
> 
> 
> Kyle,
> Well, I'd start by printing an actual content type 
> instead of depending on CGI.pm for that:
> ---
> print "content-type: text/html\n\n";

Except that that's not RFC2616-compliant, while CGI.pm's output is.

Most browsers will accept this, but you still shouldn't generate it.

> ...
> Then I would HIGHLY recommend that you not depend on 
> CGI.pm so heavily.  I would suggest you
> print out your own html, then you can see exactly what it is 
> displaying and know what to change.

I fail to see how writing code with errors is somehow
CGI.pm's fault.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: AW: param problem

[David vd Geer Inhuur tbv IPlib]

Hi Johan,

Let's tell you a secret.
I don't know what it means as well :)
Well some part then. This is just typicaly something I always re-use and
actualy never had the time to re-look at it.

Don't worry about the length by the way. Just give it a try, it never failed for
me. And maybe you might become one of the zombies (just like me), that now and
than just steals code and re-uses it without understanding what it does :)

Now let's at least give some info :

my $head = $ENV{QUERY_STRING};  ## Just read 1 of the Enironment vars and put it 
   into $head. In this case you request the query 
string.
   You might want to use google.com, look at :
   http://hoohoo.ncsa.uiuc.edu/cgi/env.html
   
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

Well This is where we have this mailinglist for. Regex is not my best part.
But as we all have to learn :)


my ${$name} = $value;

Just a way of craeting a scalar. We just found out for example : $name = "serie";
 $value = 10;

So what we do is : ${serie} = 10;
or $serie= 10;


Hhhm, relooking at the length($buffer). Could be taken out from what I can see.
Don't know what it does out there.


Regs David
--

> 
> Puh thats tought! So i have to go the hard way for it? What a pity!
> Lets see if i understand the code... Is there any source where I can read about 
>passing parameters to a perl script via the browser?
> 
> > One solution, when not using $value = param('value');
> > 
> > sub parse_form {
> > 
> >   read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
> > 
>   [Theuerkorn Johannes]  so i have to give the length of the variable name and 
>value? And what if i don´t know it before?
> > if (length($buffer) < 5) {
> >   $head = $ENV{QUERY_STRING};
> >  }
>   [Theuerkorn Johannes]  No, i don´t understand the reading part at all ... :-(
> 
> >@pairs = split(/\?/, $head); # split vars using ? as delimitor
> > foreach $pair(@pairs) {
> >($name, $value) = split(/=/, $pair); # split var and value using = as delim.
> > 
>   [Theuerkorn Johannes]  Ok, so i got the name and values somehow into the pairs 
>array and now i put it into two variables $name and $value for further use, right? 
>But again i don´t know how the values got into $head...
> 
> >$value =~ tr/+/ /;
> >$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
> > 
> > 
>   [Theuerkorn Johannes]  Ok, have to learn a lot as it seems, i definetely have 
>no clue what happens here,... OK, lets try: in the first line you change every + to a 
>blank, don´t you? And as far as I know from RegExp, in the second line you change 
>EVERYTHING to something. But to what?
> > 
> >${$name} = $value;
> > 
>   [Theuerkorn Johannes]  Hey thats cool, i definetely understand that! ;-)
> > }
> >  } # End sub parse_form
> >  
> >  
> >  
> >  Regs David
> >  -
> >  > From [EMAIL PROTECTED] Tue Jun 25 
>15:32:57 MET 2002
> > > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> > > Precedence: bulk
> > > List-Post: 
> > > List-Help: 
> > > List-Unsubscribe: 
> > > List-Subscribe: 
> > > Delivered-To: mailing list [EMAIL PROTECTED]
> > > Message-ID: 
> > > To: "'MECKLIN, JOE (ASI)'" <[EMAIL PROTECTED]>
> > > Cc: [EMAIL PROTECTED]
> > > Subject: AW: param problem
> > > Date: Tue, 25 Jun 2002 15:10:05 +0200
> > > MIME-Version: 1.0
> > > X-Mailer: Internet Mail Service (5.5.2653.19)
> > > Content-Type: text/plain;
> > charset="ISO-8859-1"
> > > Content-Transfer-Encoding: quoted-printable
> > > Content-Length: 1671
> > > Status: RO
> > > 
> > > Thanks, but this doesn´t work either, the problem with the + is that the 
>cgi:param method takes everything after the & sign as the next variable. As the 
>syntax for the param method is: 
>http://server/script.pl?variable1=value&variable2=value...etc
> > > 
> > > > -Ursprüngliche Nachricht-
> > > > Von:MECKLIN, JOE (ASI) [SMTP:[EMAIL PROTECTED]]
> > > > Gesendet am:Dienstag, 25. Juni 2002 15:05
> > > > An: 'Theuerkorn Johannes'
> > > > Betreff:RE: param problem
> > > > 
> > > > In place of the plus sign (+), try sending the html encoding +
> > > > The html on the receiving end should translate that to a plus sign.
> > > > 
> > > > 
> > > > 
> > > > -Original Message-
> > > > From: Theuerkorn Johannes [mailto:[EMAIL PROTECTED]]
> > > > Sent: Tuesday, June 25, 2002 7:59 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: cgi:param problem
> > > > 
> > > > 
> > > > Hi there, 
> > > > 
> > > > i´ve got to pass a serial number to a perl.cgi. Doing it via 

Re: Displaying Problems

[perl-dvd]

Kyle,
Well, I'd start by printing an actual content type instead of depending on CGI.pm 
for that:
---
print "content-type: text/html\n\n";
---
Second, I would condense your if to this
---
my $c = param('c');
my $content = $c;
$content = "\n" if ($c eq "h" or $c eq "eh" or $c eq "hd" or $c eq "p" or $c eq "c" or 
$c eq "su");
---
Then I would HIGHLY recommend that you not depend on CGI.pm so heavily.  I would 
suggest you
print out your own html, then you can see exactly what it is displaying and know what 
to change.  If
you wanted to print it all in one clump, you could do it like this.
---
# the qq^ makes it use ^ as the quote.  Just make sure if you us a ^ inside that you 
escape it (like
this \^ )
print qq^


$thetitle





^;
---

Trust me on this one, it will save you so much headache if you will just print your 
own html.

Regards,
David


- Original Message -
From: "Kyle Babich" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 24, 2002 2:09 PM
Subject: Displaying Problems


For the following the syntax is correct but when I try to open it
nothing displays, what should I change?

#!/usr/bin/perl -wT
use strict;
use CGI::Pretty qw/ :standard /;
$CGI::DISABLE_UPLOADS = 1;
$CGI::POST_MAX = 512 * 1024;

print header ( "text/html" );

my $date = localtime;

my $c = param('c');
my $content = "c";

if ($c eq "h") {
   $content = qq{\n};
} elsif ($c eq "eh") {
   $content = qq{\n};
} elsif ($c eq "hd") {
   $content = qq{\n};
} elsif ($c eq "p") {
   $content = qq{\n};
} elsif ($c eq "c") {
   $content = qq{\n};
} elsif ($c eq "su") {
   $content = qq{\n};
}

my @nav = ("Home","E-Mail Hosting","Help
Desk","Policies","Contact","Signup");

my @loc = ("index.cgi?c=h","index.cgi?c=eh","index.cgi?c=hd","index.cgi?
c=p",
   "index.cgi?c=c","index.cgi?c=su");

print start_html(
  -title => "IMAP.cc E-Mail Hosting",
   -head  => Link(
   {
   -rel => "stylesheet",
   -type => "text/css",
   -href => "style.css"
   }
   ),
   ),
   body( -bgcolor => "\#FF" ),
   table({
   -width => "95\%",
   -cellspacing => "0",
   -cellpadding => "0",
   -border => "1",
   -bordercolor => "\#00"},
   tbody(
Tr(
td( {-width => "100\%"},
   table({
-width => "100\%",
-cellspacing => "0",
-cellpadding => "1",
-border => "1",
-bordercolor => "\#00"
-align => "center"},
   tbody(
Tr(
td( {-width => "100\%",
-bgcolor => "\#00",
-align => "center"},
   Font({
-face => "Verdana, Arial, Times New Roman",
-size => "4",
-color => "\#FF"},
"IMAP.cc"
)
),),),),),),),),
end_html
--


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Barcode with Perl

[Geraint Jones]

On Tuesday 25 June 2002 1:58 pm, Fred Sahakian wrote:
> Anyone know of a program that can create barcodes on the screen from
> entered numbers?
>
> thanks!
Found this on CPAN:
http://www.perl.com/CPAN-local/modules/by-module/Barcode/

-- 
Geraint Jones

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: AW: param problem

[Theuerkorn Johannes]

Puh thats tought! So i have to go the hard way for it? What a pity!
Lets see if i understand the code... Is there any source where I can read about 
passing parameters to a perl script via the browser?

> One solution, when not using $value = param('value');
> 
> sub parse_form {
> 
>   read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
> 
[Theuerkorn Johannes]  so i have to give the length of the variable name and 
value? And what if i don´t know it before?
> if (length($buffer) < 5) {
>   $head = $ENV{QUERY_STRING};
>  }
[Theuerkorn Johannes]  No, i don´t understand the reading part at all ... :-(

>@pairs = split(/\?/, $head); # split vars using ? as delimitor
> foreach $pair(@pairs) {
>($name, $value) = split(/=/, $pair); # split var and value using = as delim.
> 
[Theuerkorn Johannes]  Ok, so i got the name and values somehow into the pairs 
array and now i put it into two variables $name and $value for further use, right? But 
again i don´t know how the values got into $head...

>$value =~ tr/+/ /;
>$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
> 
> 
[Theuerkorn Johannes]  Ok, have to learn a lot as it seems, i definetely have 
no clue what happens here,... OK, lets try: in the first line you change every + to a 
blank, don´t you? And as far as I know from RegExp, in the second line you change 
EVERYTHING to something. But to what?
> 
>${$name} = $value;
> 
[Theuerkorn Johannes]  Hey thats cool, i definetely understand that! ;-)
> }
>  } # End sub parse_form
>  
>  
>  
>  Regs David
>  -
>  > From [EMAIL PROTECTED] Tue Jun 25 
>15:32:57 MET 2002
> > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> > Precedence: bulk
> > List-Post: 
> > List-Help: 
> > List-Unsubscribe: 
> > List-Subscribe: 
> > Delivered-To: mailing list [EMAIL PROTECTED]
> > Message-ID: 
> > To: "'MECKLIN, JOE (ASI)'" <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> > Subject: AW: param problem
> > Date: Tue, 25 Jun 2002 15:10:05 +0200
> > MIME-Version: 1.0
> > X-Mailer: Internet Mail Service (5.5.2653.19)
> > Content-Type: text/plain;
>   charset="ISO-8859-1"
> > Content-Transfer-Encoding: quoted-printable
> > Content-Length: 1671
> > Status: RO
> > 
> > Thanks, but this doesn´t work either, the problem with the + is that the 
>cgi:param method takes everything after the & sign as the next variable. As the 
>syntax for the param method is: 
>http://server/script.pl?variable1=value&variable2=value...etc
> > 
> > > -Ursprüngliche Nachricht-
> > > Von:  MECKLIN, JOE (ASI) [SMTP:[EMAIL PROTECTED]]
> > > Gesendet am:  Dienstag, 25. Juni 2002 15:05
> > > An:   'Theuerkorn Johannes'
> > > Betreff:  RE: param problem
> > > 
> > > In place of the plus sign (+), try sending the html encoding +
> > > The html on the receiving end should translate that to a plus sign.
> > > 
> > > 
> > > 
> > > -Original Message-
> > > From: Theuerkorn Johannes [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, June 25, 2002 7:59 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: cgi:param problem
> > > 
> > > 
> > > Hi there, 
> > > 
> > > i´ve got to pass a serial number to a perl.cgi. Doing it via the cgi:param
> > > funktion seems not to work.
> > > 
> > > 
> > > >use strict;
> > > >use CGI;
> > > >use DBI;
> > > >my $cgi_obj = new CGI;
> > > >my $seriennummer = $cgi_obj->param("seriennummer");
> > > 
> > > Passing http://server/script4.pl?seriennummer=CN+/P422
> > > 
> > > results in a variable seriennummer=CN/P422
> > > 
> > > As i want to use the variable seriennummer for an SQL Query later, this> 
> > > doesn´t work.
> > > 
> > > Any possibility passing the + to my cgi Script? (\+ doesn´t work, either '+'
> > > or "+")
> > > 
> > > Johannes
> > > 
> > > -- 
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > -- 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Barcode with Perl

[Fred Sahakian]

Anyone know of a program that can create barcodes on the screen from entered numbers?

thanks!

Re: AW: param problem

[Felix Geerinckx]

on Tue, 25 Jun 2002 13:10:05 GMT, [EMAIL PROTECTED]
(Theuerkorn Johannes) wrote: 

> Thanks, but this doesn´t work either, the problem with the + is
> that the cgi:param method takes everything after the & sign as the
> next variable. As the syntax for the param method is:
> http://server/script.pl?variable1=value&variable2=value...etc 

It's not '+' but '%2B':

#! perl -w
use strict;

use URI::Escape;
print uri_escape("+");  # prints %2B

-- 
felix

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: param problem

[David vd Geer Inhuur tbv IPlib]

One solution, when not using $value = param('value');

sub parse_form {

  read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
if (length($buffer) < 5) {
  $head = $ENV{QUERY_STRING};
 }

   @pairs = split(/\?/, $head); # split vars using ? as delimitor
foreach $pair(@pairs) {
   ($name, $value) = split(/=/, $pair); # split var and value using = as delim.

   $value =~ tr/+/ /;
   $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

   ${$name} = $value;
}
 } # End sub parse_form
 
 
 
 Regs David
 -
 > From [EMAIL PROTECTED] Tue Jun 25 
 >15:32:57 MET 2002
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Precedence: bulk
> List-Post: 
> List-Help: 
> List-Unsubscribe: 
> List-Subscribe: 
> Delivered-To: mailing list [EMAIL PROTECTED]
> Message-ID: 
> To: "'MECKLIN, JOE (ASI)'" <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: AW: param problem
> Date: Tue, 25 Jun 2002 15:10:05 +0200
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2653.19)
> Content-Type: text/plain;
charset="ISO-8859-1"
> Content-Transfer-Encoding: quoted-printable
> Content-Length: 1671
> Status: RO
> 
> Thanks, but this doesn´t work either, the problem with the + is that the 
>cgi:param method takes everything after the & sign as the next variable. As the 
>syntax for the param method is: 
>http://server/script.pl?variable1=value&variable2=value...etc
> 
> > -Ursprüngliche Nachricht-
> > Von:MECKLIN, JOE (ASI) [SMTP:[EMAIL PROTECTED]]
> > Gesendet am:Dienstag, 25. Juni 2002 15:05
> > An: 'Theuerkorn Johannes'
> > Betreff:RE: param problem
> > 
> > In place of the plus sign (+), try sending the html encoding +
> > The html on the receiving end should translate that to a plus sign.
> > 
> > 
> > 
> > -Original Message-
> > From: Theuerkorn Johannes [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, June 25, 2002 7:59 AM
> > To: [EMAIL PROTECTED]
> > Subject: cgi:param problem
> > 
> > 
> > Hi there, 
> > 
> > i´ve got to pass a serial number to a perl.cgi. Doing it via the cgi:param
> > funktion seems not to work.
> > 
> > 
> > >use strict;
> > >use CGI;
> > >use DBI;
> > >my $cgi_obj = new CGI;
> > >my $seriennummer = $cgi_obj->param("seriennummer");
> > 
> > Passing http://server/script4.pl?seriennummer=CN+/P422
> > 
> > results in a variable seriennummer=CN/P422
> > 
> > As i want to use the variable seriennummer for an SQL Query later, this
> > doesn´t work.
> > 
> > Any possibility passing the + to my cgi Script? (\+ doesn´t work, either '+'
> > or "+")
> > 
> > Johannes
> > 
> > -- 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> -- 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: passing variables in POST

[Marty Landman]

At 05:47 AM 6/25/02 -0700, John Brooking wrote:

>   As David says, the place that you can see the
>"hidden" variables is in the page where the form is,
>before you submit it.

Got that now, thx John.

>   But wait, there's more! Even if your script *did*
>check the referer, that's no protection either! An
>experienced programmer can easily use Perl's LWP
>module or its equivalent in some other language to
>make the request with a faked referer variable. So
>really, POST variables are no more secure than GET
>variables, it just takes a little more doing to fake
>them.

Didn't realize this. What exactly is the right procedure then to safeguard 
scripts such as formmailers from being hijacked?

>By the way, I'm still not a security expert, so
>don't take my word as the final one either!

Me either, eager to learn and improve myself.

Marty

--
SIMPL WebSite Creation: http://face2interface.com/Home/Demo.shtml


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: param problem

[Theuerkorn Johannes]

Thanks, but this doesn´t work either, the problem with the + is that the cgi:param 
method takes everything after the & sign as the next variable. As the syntax for the 
param method is: http://server/script.pl?variable1=value&variable2=value...etc

> -Ursprüngliche Nachricht-
> Von:  MECKLIN, JOE (ASI) [SMTP:[EMAIL PROTECTED]]
> Gesendet am:  Dienstag, 25. Juni 2002 15:05
> An:   'Theuerkorn Johannes'
> Betreff:  RE: param problem
> 
> In place of the plus sign (+), try sending the html encoding +
> The html on the receiving end should translate that to a plus sign.
> 
> 
> 
> -Original Message-
> From: Theuerkorn Johannes [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 25, 2002 7:59 AM
> To: [EMAIL PROTECTED]
> Subject: cgi:param problem
> 
> 
> Hi there, 
> 
> i´ve got to pass a serial number to a perl.cgi. Doing it via the cgi:param
> funktion seems not to work.
> 
> 
> >use strict;
> >use CGI;
> >use DBI;
> >my $cgi_obj = new CGI;
> >my $seriennummer = $cgi_obj->param("seriennummer");
> 
> Passing http://server/script4.pl?seriennummer=CN+/P422
> 
> results in a variable seriennummer=CN/P422
> 
> As i want to use the variable seriennummer for an SQL Query later, this
> doesn´t work.
> 
> Any possibility passing the + to my cgi Script? (\+ doesn´t work, either '+'
> or "+")
> 
> Johannes
> 
> -- 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Displaying Problems

[kb]

I still can't get it to work even with those changes.

Quoting Bob Showalter <[EMAIL PROTECTED]>:

> > -Original Message-
> > From: Kyle Babich [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 24, 2002 4:09 PM
> > To: [EMAIL PROTECTED]
> > Subject: Displaying Problems
> > 
> > 
> > For the following the syntax is correct but when I try to open it 
> > nothing displays, what should I change?
> 
> There are some errors. The following patch shows what I had
> to change to make it run:
> 
> 3c3
> < use CGI::Pretty qw/ :standard /;
> ---
> > use CGI::Pretty qw/ :standard tbody /;
> 60c60
> <   -bordercolor => "\#00"
> ---
> >   -bordercolor => "\#00",
> 67c67
>  ---
> >font({
> 
> > 
> > #!/usr/bin/perl -wT
> > use strict;
> > use CGI::Pretty qw/ :standard /;
> > $CGI::DISABLE_UPLOADS = 1;
> > $CGI::POST_MAX = 512 * 1024;
> > 
> > print header ( "text/html" );
> > 
> > my $date = localtime;
> > 
> > my $c = param('c');
> > my $content = "c";
> > 
> > if ($c eq "h") {
> >$content = qq{\n};
> > } elsif ($c eq "eh") {
> >$content = qq{\n};
> > } elsif ($c eq "hd") {
> >$content = qq{\n};
> > } elsif ($c eq "p") {
> >$content = qq{\n};
> > } elsif ($c eq "c") {
> >$content = qq{\n};
> > } elsif ($c eq "su") {
> >$content = qq{\n};
> > }
> > 
> > my @nav = ("Home","E-Mail Hosting","Help 
> > Desk","Policies","Contact","Signup");
> > 
> > my @loc = 
> > ("index.cgi?c=h","index.cgi?c=eh","index.cgi?c=hd","index.cgi?
> > c=p",
> >"index.cgi?c=c","index.cgi?c=su");
> > 
> > print start_html(
> >   -title => "IMAP.cc E-Mail Hosting",
> >-head  => Link( 
> >{ 
> >-rel => "stylesheet",
> >-type => "text/css",
> >-href => "style.css"
> >}
> >),
> >),
> >body( -bgcolor => "\#FF" ),
> >table({
> >-width => "95\%",
> >-cellspacing => "0",
> >-cellpadding => "0",
> >-border => "1",
> >-bordercolor => "\#00"},
> >tbody(
> > Tr(
> > td( {-width => "100\%"},
> >table({
> > -width => "100\%",
> > -cellspacing => "0",
> > -cellpadding => "1",
> > -border => "1",
> > -bordercolor => "\#00"
> > -align => "center"},
> >tbody(
> > Tr(
> > td( {-width => "100\%",
> > -bgcolor => "\#00",
> > -align => "center"},
> >Font({
> > -face => "Verdana, Arial, Times New Roman",
> > -size => "4",
> > -color => "\#FF"},
> > "IMAP.cc"
> > )
> > ),),),),),),),),
> > end_html
> 
> 




-
This mail sent through IMP: http://horde.org/imp/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Not displaying in browser

[Bob Showalter]

> -Original Message-
> From: Kyle Babich [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 24, 2002 7:44 PM
> To: [EMAIL PROTECTED]
> Subject: Not displaying in browser
> 
> 
> When I load this in the browser I just get a blank page.  The source 
> shows declaration, html, body, head, and meta tags, but that's it.  
> What should I change?
> 
> #!/usr/bin/perl -wT
> use strict;
> use CGI::Pretty qw/ :standard /;
> $CGI::DISABLE_UPLOADS = 1;
> $CGI::POST_MAX = 512 * 1024;
> 
> print header ( "text/html" );
> 
> my $date = localtime;
> 
> my $c = param('c');
> my $content = "c";
> 
> if ($c eq "h") {
>$content = qq{\n};
> } elsif ($c eq "eh") {
>$content = qq{\n};
> } elsif ($c eq "hd") {
>$content = qq{\n};
> } elsif ($c eq "p") {
>$content = qq{\n};
> } elsif ($c eq "c") {
>$content = qq{\n};
> } elsif ($c eq "su") {
>$content = qq{\n};
> }
> 
> my @nav = ("Home","E-Mail Hosting","Help 
> Desk","Policies","Contact","Signup");
> 
> my @loc = 
> ("index.cgi?c=h","index.cgi?c=eh","index.cgi?c=hd","index.cgi?
> c=p",
>"index.cgi?c=c","index.cgi?c=su");
> 
> print start_html(
>   -title => "IMAP.cc E-Mail Hosting",
>-head  => Link( 
>{ 
>-rel => "stylesheet",
>-type => "text/css",
>-href => "style.css"
>}
>),
>),
>body( -bgcolor => "\#FF" ),
>table({
>-width => "95\%",
>-cellspacing => "0",
>-cellpadding => "0",
>-border => "1",
>-bordercolor => "\#00"},
>tbody(
>   Tr(
>   td( {-width => "100\%"},
>table({
>   -width => "100\%",
>   -cellspacing => "0",
>   -cellpadding => "1",
>   -border => "1",
>   -bordercolor => "\#00"
>   -align => "center"},
>tbody(
>   Tr(
>   td( {-width => "100\%",
>   -bgcolor => "\#00",
>   -align => "center"},
>font({
>   -face => "Verdana, Arial, Times New Roman",
>   -size => "4",
>   -color => "\#FF"},
>   "IMAP.cc"
>   )
>   ),),),),),),),),
> end_html;

Similar problems to previous post. Check your server error logs;
Perl is generating error messages.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Displaying Problems

[Bob Showalter]

> -Original Message-
> From: Kyle Babich [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 24, 2002 4:09 PM
> To: [EMAIL PROTECTED]
> Subject: Displaying Problems
> 
> 
> For the following the syntax is correct but when I try to open it 
> nothing displays, what should I change?

There are some errors. The following patch shows what I had
to change to make it run:

3c3
< use CGI::Pretty qw/ :standard /;
---
> use CGI::Pretty qw/ :standard tbody /;
60c60
<   -bordercolor => "\#00"
---
>   -bordercolor => "\#00",
67c67
font({

> 
> #!/usr/bin/perl -wT
> use strict;
> use CGI::Pretty qw/ :standard /;
> $CGI::DISABLE_UPLOADS = 1;
> $CGI::POST_MAX = 512 * 1024;
> 
> print header ( "text/html" );
> 
> my $date = localtime;
> 
> my $c = param('c');
> my $content = "c";
> 
> if ($c eq "h") {
>$content = qq{\n};
> } elsif ($c eq "eh") {
>$content = qq{\n};
> } elsif ($c eq "hd") {
>$content = qq{\n};
> } elsif ($c eq "p") {
>$content = qq{\n};
> } elsif ($c eq "c") {
>$content = qq{\n};
> } elsif ($c eq "su") {
>$content = qq{\n};
> }
> 
> my @nav = ("Home","E-Mail Hosting","Help 
> Desk","Policies","Contact","Signup");
> 
> my @loc = 
> ("index.cgi?c=h","index.cgi?c=eh","index.cgi?c=hd","index.cgi?
> c=p",
>"index.cgi?c=c","index.cgi?c=su");
> 
> print start_html(
>   -title => "IMAP.cc E-Mail Hosting",
>-head  => Link( 
>{ 
>-rel => "stylesheet",
>-type => "text/css",
>-href => "style.css"
>}
>),
>),
>body( -bgcolor => "\#FF" ),
>table({
>-width => "95\%",
>-cellspacing => "0",
>-cellpadding => "0",
>-border => "1",
>-bordercolor => "\#00"},
>tbody(
>   Tr(
>   td( {-width => "100\%"},
>table({
>   -width => "100\%",
>   -cellspacing => "0",
>   -cellpadding => "1",
>   -border => "1",
>   -bordercolor => "\#00"
>   -align => "center"},
>tbody(
>   Tr(
>   td( {-width => "100\%",
>   -bgcolor => "\#00",
>   -align => "center"},
>Font({
>   -face => "Verdana, Arial, Times New Roman",
>   -size => "4",
>   -color => "\#FF"},
>   "IMAP.cc"
>   )
>   ),),),),),),),),
> end_html

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: passing variables in POST

[John Brooking]

Marty,

  David's explaining it pretty well, but let me take
another crack at it. I was in your position about a
year ago and got royally (and publically) flamed on
the perl beginners list by a security admin for
deigning to give CGI advice without knowing this, so I
got what you might call a crash course!

  As David says, the place that you can see the
"hidden" variables is in the page where the form is,
before you submit it. It is true that once you submit
it, you don't see them go, and once you arrive at the
target script, they are not available. But they can be
discovered by looking at the page source before
submission.

  So what? The user can't change the page source,
right? Well, wrong. Anyone could save a copy of the
page to their own file system, modify the "hidden"
values there, and submit that modified page to your
server! Your server script may or may not be checking
the "referer" [sic] environment variable to ensure
that only submissions originating from your site are
valid. If it's not, this bogus and potentially
malevolent request would get right through!

  But wait, there's more! Even if your script *did*
check the referer, that's no protection either! An
experienced programmer can easily use Perl's LWP
module or its equivalent in some other language to
make the request with a faked referer variable. So
really, POST variables are no more secure than GET
variables, it just takes a little more doing to fake
them.

  Does this matter in your situation? If it's a
session id, it seems to me that either it's the
correct session id that you gave them, or it's
something else they made up, in which case it's
probably invalid and so your script will just ignore
it or throw an error. (It's theoretically possible I
suppose that they might guess a number that's someone
else's current session id, but that seems extremely
unlikely.) And if you're passing it to log them off,
even if they attempt to use it again, they'll be
logged off by then, so it won't work anymore anyway.
(But then, why does it even matter if it's hidden or
not?)

  So in the end, it's your decision. But it's
important that you understand it all so that you can
make an informed decision.

   By the way, I'm still not a security expert, so
don't take my word as the final one either!

- John

--- Marty Landman <[EMAIL PROTECTED]> wrote:
> At 06:06 AM 6/25/02 -0500, David T-G wrote:
> 
> >If the variables are in the page to be in the form
> to be
> >sent back via POST, then the user can find them,
> period.
> >
> >Try it yourself: set up something via POST and then
> surf to the page
> >and then "view source" or the equivalent in your
> browser (and if there
> >isn't an equivalent then find a browser, even if
> just for a moment,
> >that DOES have it) and look and see your data
> hanging right out there
> >for all to see.
> 
> David,
> 
> Sorry but I don't get what you mean here. When I
> have a page call a program 
> with info from a form being posted then the program
> picks up the data and 
> then creates whatever output web page is
> appropriate. The posted data comes 
> in via STDIN so unlike a GET where the data is
> actually part of the URL, in 
> a POST it isn't viewable from the browser.


=
"Now it's over, I'm dead, and I haven't done anything that I want; or, I'm still 
alive, and there's nothing I want to do." - They Might Be Giants, http://www.tmbg.com

__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: passing variables in POST

[David T-G]

Marty --

...and then Marty Landman said...
% 
% At 06:50 AM 6/25/02 -0500, David T-G wrote:
% 
...
% >view the page source and you will see the form structure and the hidden
% >(note that "hidden" simply means "don't bother to try to display on the
% >page", not "secretly encrypted or made to disappear so that nobody can
% >find it") variable right there.
% 
% Oops, sorry I didn't follow this thread from the beginning David or I 

I wondered about that...


% would've understood your point; which is that hidden form fields aren't 
% and are certainly no place to put data that shouldn't be available over the 
% web for site visitors to see.

Yep.


% 
% Right?

Absolutely.


% 
% >Well, the browser has to know what to send back to your script as STDIN,
% >no?  And if it knows what to send, then it must have that on the page
% >somewhere, no?  And if it's on the page somewhere then the user can see
% >it, no?
% 
% Absolutely... so can a program for using LWP for example. I could even find 
% it using the GRABURL Windows app from a  batch exec, then parse out the 
% hidden form fields on my PC using Java or C++.

Of course.  I just wanted to show the easy example, particularly since
it's my understanding that the goal is to keep the user much less some
intelligent hacker, from seeing this data -- and the user pretty much
only has 'view source' at his disposal, but that's more than enough in
this case.


% 
% The proper way to handle this kind of requirement imo is to use a hidden 
% form field with a key, and then have the server side pgm validate the 
% HTTP_REFERER. So the key itself is of no value unless the authenticated 
% referer coupled with the key tells the server pgm to access the secured 
% info using that key.

Sounds good to me.  I actually don't have enough info or experience to
design even a moderately secure system; that's why I'm following this
thread.  [My particular target application is a cookie-less clean-URL
SSL script framework; I want something robust and secure so that I can
run various applications, like a calendar or an anonymizer-style wrapper
or whatever, through this script *and* be "different" in two different
windows (maybe I want to talk to two hotmail accounts at once on the same
PC, for instance) and I don't want to have to turn on cookies (though
this script should handle them, if things were REALLY written elegantly)
on the PC, where I leave them and javascript off.]

As with most security and cryptography, though, some holes are easy to
spot and almost as easy to explain, so I jumped in the fray to clarify.


% 
% But you already knew that. :)

Well, yeah, but sometimes it takes a while for folks to believe it ;-)


% 
% Marty
% 
% --
% SIMPL WebSite Creation: http://face2interface.com/Home/Demo.shtml


HAND

:-D
-- 
David T-G  * It's easier to fight for one's principles
(play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg!




msg05537/pgp0.pgp
Description: PGP signature

Re: passing variables in POST

[Marty Landman]

At 06:50 AM 6/25/02 -0500, David T-G wrote:

>When you have page1 loaded and you're about to press the submit button
>to send it, and your secret var1, off to the script, don't; instead,
>view the page source and you will see the form structure and the hidden
>(note that "hidden" simply means "don't bother to try to display on the
>page", not "secretly encrypted or made to disappear so that nobody can
>find it") variable right there.

Oops, sorry I didn't follow this thread from the beginning David or I 
would've understood your point; which is that hidden form fields aren't... 
and are certainly no place to put data that shouldn't be available over the 
web for site visitors to see.

Right?

>Well, the browser has to know what to send back to your script as STDIN,
>no?  And if it knows what to send, then it must have that on the page
>somewhere, no?  And if it's on the page somewhere then the user can see
>it, no?

Absolutely... so can a program for using LWP for example. I could even find 
it using the GRABURL Windows app from a  batch exec, then parse out the 
hidden form fields on my PC using Java or C++.

The proper way to handle this kind of requirement imo is to use a hidden 
form field with a key, and then have the server side pgm validate the 
HTTP_REFERER. So the key itself is of no value unless the authenticated 
referer coupled with the key tells the server pgm to access the secured 
info using that key.

But you already knew that. :)

Marty

--
SIMPL WebSite Creation: http://face2interface.com/Home/Demo.shtml


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: passing variables in POST

[David T-G]

Marty --

...and then Marty Landman said...
% 
% At 06:06 AM 6/25/02 -0500, David T-G wrote:
% 
% >If the variables are in the page to be in the form to be
% >sent back via POST, then the user can find them, period.
% >
% >Try it yourself: set up something via POST and then surf to the page
% >and then "view source" or the equivalent in your browser (and if there
% >isn't an equivalent then find a browser, even if just for a moment,
% >that DOES have it) and look and see your data hanging right out there
% >for all to see.
% 
% David,
% 
% Sorry but I don't get what you mean here. When I have a page call a program 
% with info from a form being posted then the program picks up the data and 
% then creates whatever output web page is appropriate. The posted data comes 

Right.  That makes sense.  So you have something like

  page1   scriptpage2
  form   -->  think...  ->  some
var1process...output

right?


% in via STDIN so unlike a GET where the data is actually part of the URL, in 
% a POST it isn't viewable from the browser.

When you have page1 loaded and you're about to press the submit button
to send it, and your secret var1, off to the script, don't; instead,
view the page source and you will see the form structure and the hidden
(note that "hidden" simply means "don't bother to try to display on the
page", not "secretly encrypted or made to disappear so that nobody can
find it") variable right there.


% 
% If I'm all wrong about this please give a specific example... and sorry if 
% I'm being thick. Also I'm not claiming that POST is safe as is, that's what 

I trust that the example above will either illustrate the problem *or*
clarify any confusion; it's certainly possible that I'm misunderstanding
the process you propose.

Your turn to tell me if *I* am being thick :-)


% SSL is for to encrypt the data between the server and client and vice 
% versa. Only I don't get the exposure you're talking about. Didn't realize 
% that STDIN was part of the browser's viewable source code.

Well, the browser has to know what to send back to your script as STDIN,
no?  And if it knows what to send, then it must have that on the page
somewhere, no?  And if it's on the page somewhere then the user can see
it, no?


% 
% Marty
% 
% --
% SIMPL WebSite Creation: http://face2interface.com/Home/Demo.shtml


HTH & HAND

:-D
-- 
David T-G  * It's easier to fight for one's principles
(play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg!




msg05535/pgp0.pgp
Description: PGP signature

Re: passing variables in POST

[Marty Landman]

At 06:06 AM 6/25/02 -0500, David T-G wrote:

>If the variables are in the page to be in the form to be
>sent back via POST, then the user can find them, period.
>
>Try it yourself: set up something via POST and then surf to the page
>and then "view source" or the equivalent in your browser (and if there
>isn't an equivalent then find a browser, even if just for a moment,
>that DOES have it) and look and see your data hanging right out there
>for all to see.

David,

Sorry but I don't get what you mean here. When I have a page call a program 
with info from a form being posted then the program picks up the data and 
then creates whatever output web page is appropriate. The posted data comes 
in via STDIN so unlike a GET where the data is actually part of the URL, in 
a POST it isn't viewable from the browser.

If I'm all wrong about this please give a specific example... and sorry if 
I'm being thick. Also I'm not claiming that POST is safe as is, that's what 
SSL is for to encrypt the data between the server and client and vice 
versa. Only I don't get the exposure you're talking about. Didn't realize 
that STDIN was part of the browser's viewable source code.

Marty

--
SIMPL WebSite Creation: http://face2interface.com/Home/Demo.shtml


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: passing variables in POST

[David T-G]

Niko, et al --

...and then Niko Gunadi said...
% 
% On Mon, Jun 24, 2002 at 02:35:06PM -0700, Ovid wrote:
% >Niko,
% >
% >If you pass the variables to the page, the user can find them, period.  If you 
control the output
...
% 
%   From what i know (which is limited :), if we pass the variable in POST
%   method, the user can't find out what we have passed, can they ?

Yes s/he can.  If the variables are in the page to be in the form to be
sent back via POST, then the user can find them, period.

Try it yourself: set up something via POST and then surf to the page
and then "view source" or the equivalent in your browser (and if there
isn't an equivalent then find a browser, even if just for a moment,
that DOES have it) and look and see your data hanging right out there
for all to see.


HTH & HAND

:-D
-- 
David T-G  * It's easier to fight for one's principles
(play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie
(work) [EMAIL PROTECTED]
http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg!




msg05533/pgp0.pgp
Description: PGP signature

Not displaying in browser

[Kyle Babich]

When I load this in the browser I just get a blank page.  The source 
shows declaration, html, body, head, and meta tags, but that's it.  
What should I change?

#!/usr/bin/perl -wT
use strict;
use CGI::Pretty qw/ :standard /;
$CGI::DISABLE_UPLOADS = 1;
$CGI::POST_MAX = 512 * 1024;

print header ( "text/html" );

my $date = localtime;

my $c = param('c');
my $content = "c";

if ($c eq "h") {
   $content = qq{\n};
} elsif ($c eq "eh") {
   $content = qq{\n};
} elsif ($c eq "hd") {
   $content = qq{\n};
} elsif ($c eq "p") {
   $content = qq{\n};
} elsif ($c eq "c") {
   $content = qq{\n};
} elsif ($c eq "su") {
   $content = qq{\n};
}

my @nav = ("Home","E-Mail Hosting","Help 
Desk","Policies","Contact","Signup");

my @loc = ("index.cgi?c=h","index.cgi?c=eh","index.cgi?c=hd","index.cgi?
c=p",
   "index.cgi?c=c","index.cgi?c=su");

print start_html(
  -title => "IMAP.cc E-Mail Hosting",
   -head  => Link( 
   { 
   -rel => "stylesheet",
   -type => "text/css",
   -href => "style.css"
   }
   ),
   ),
   body( -bgcolor => "\#FF" ),
   table({
   -width => "95\%",
   -cellspacing => "0",
   -cellpadding => "0",
   -border => "1",
   -bordercolor => "\#00"},
   tbody(
Tr(
td( {-width => "100\%"},
   table({
-width => "100\%",
-cellspacing => "0",
-cellpadding => "1",
-border => "1",
-bordercolor => "\#00"
-align => "center"},
   tbody(
Tr(
td( {-width => "100\%",
-bgcolor => "\#00",
-align => "center"},
   font({
-face => "Verdana, Arial, Times New Roman",
-size => "4",
-color => "\#FF"},
"IMAP.cc"
)
),),),),),),),),
end_html;

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Displaying Problems

[Kyle Babich]

For the following the syntax is correct but when I try to open it 
nothing displays, what should I change?

#!/usr/bin/perl -wT
use strict;
use CGI::Pretty qw/ :standard /;
$CGI::DISABLE_UPLOADS = 1;
$CGI::POST_MAX = 512 * 1024;

print header ( "text/html" );

my $date = localtime;

my $c = param('c');
my $content = "c";

if ($c eq "h") {
   $content = qq{\n};
} elsif ($c eq "eh") {
   $content = qq{\n};
} elsif ($c eq "hd") {
   $content = qq{\n};
} elsif ($c eq "p") {
   $content = qq{\n};
} elsif ($c eq "c") {
   $content = qq{\n};
} elsif ($c eq "su") {
   $content = qq{\n};
}

my @nav = ("Home","E-Mail Hosting","Help 
Desk","Policies","Contact","Signup");

my @loc = ("index.cgi?c=h","index.cgi?c=eh","index.cgi?c=hd","index.cgi?
c=p",
   "index.cgi?c=c","index.cgi?c=su");

print start_html(
  -title => "IMAP.cc E-Mail Hosting",
   -head  => Link( 
   { 
   -rel => "stylesheet",
   -type => "text/css",
   -href => "style.css"
   }
   ),
   ),
   body( -bgcolor => "\#FF" ),
   table({
   -width => "95\%",
   -cellspacing => "0",
   -cellpadding => "0",
   -border => "1",
   -bordercolor => "\#00"},
   tbody(
Tr(
td( {-width => "100\%"},
   table({
-width => "100\%",
-cellspacing => "0",
-cellpadding => "1",
-border => "1",
-bordercolor => "\#00"
-align => "center"},
   tbody(
Tr(
td( {-width => "100\%",
-bgcolor => "\#00",
-align => "center"},
   Font({
-face => "Verdana, Arial, Times New Roman",
-size => "4",
-color => "\#FF"},
"IMAP.cc"
)
),),),),),),),),
end_html
-- 


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Running Modules

[David vd Geer Inhuur tbv IPlib]

Hi,

Don't forget to close the FH :

close();


Regs David
-

> 
> Greetings All,
>  
> I have the following code, from which I attempt to call the module
> “Test”
> #!/usr/local/bin/perl
> ###
> ### Program name:  demo.pl
> ### Created By:Theresa Mullin
>  
> require "cgi.lib";
>  
> ### Include the CGI stuff
> use CGI qw(:standard);
>  
> ### Include the database access stuff
> use DBI;
>  
> ### Push location of user created packages onto @INC array
> push(@INC,"/home/tmullin/perl/libs");  
>  
> use Test;
>  
> ### Force "no buffering" for output
> $| = 1;
>  
>  
> ### Parse the arguments sent in from the browser
> &ReadParse();
>  
> ### Open log file
> open DEMO_LOG, ">/home/tmullin/demo_log"||die "unable to open log file";
>  
> print DEMO_LOG "Begin processing...\n";
> print DEMO_LOG "array INC:  @INC\n";
> print DEMO_LOG "Database selected is:  $dbase\n";
>  
>  
>  
> …Here is module Test:
>  
> #!/usr/bin/perl
>  
> ###  Program Name:  Test.pm
> ###  Created By:Theresa Mullin
> ###  Date:  5/20/02
>  
> package Test;
>  
> $dbase = "TEST";
> print "And to all a good night \n";  
>  
> The code appears to execute, and no error messages are generated.
> However, the value of $dbase is never written to the log file.
> Any advice you can give would be helpful.
> Thanks,
> T.
>  
>  
> Theresa M. Mullin
> Programmer/Analyst
> Administrative Computing
> Northern Essex Community College
> 100 Elliott Way
> Haverhill, MA  01830
> (978) 556-3757
> [EMAIL PROTECTED]
>  
> 
> --=_NextPart_000_0003_01C21B8B.A3BFB810--
> 
> 

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What editor for Perl do you recommend?

[Geraint Jones]

On Monday 24 June 2002 5:06 am, Octavian Rasnita wrote:
> Hi all,
>
> Can you recommend me a good editor for Perl scripts that runs under
> Windows? It should:
>
> 1. Save the text with Unix end of lines.
> 2. Write somewhere the current line I am in.
> 3. Not necessary but it would be wonderful to have a hotkey to jump from
> subroutine to subroutine, or to list the subroutines in a combo or list and
> to be able to choose the one I want from there.
>
> With all the success of Perl, I am wondering why isn't there any accessible
> good and proffessional editor for Windows.
>
> Thank you.
>
> Teddy Center for the blind: http://teddy.fcc.ro/
> Mail: [EMAIL PROTECTED]

Try Open Perl IDE, it looks like MS Visual Studio.
http://open-perl-ide.sourceforge.net/

I've only tinkered with it a little, but I think it will be my editor of 
choice on Windows. I'm still searching for something similar for Linux...
-- 
Geraint Jones

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]