SSI from script

2004-09-22 Thread Ramon Chavez
Hi everyone.

I'm trying to call a SSI from a page generated by a Perl script. Obviously the SSI 
can't be called because it is not an HTML file. But if I use the .htaccess parsing 
method, a with .shtml, (AddHandler server-parsed .pl) I got all the code of my script 
listed.

This SSI will call another .pl , a counter to be precise.
I could include the code of the counter in the main script, but I didn't wrote the 
counter and don't want to do anything wrong, I mean I respect other's work.
I was thinking in 'use' or 'require', but it's not about the functions in the counter, 
it's about the whole output.

Any advice on where to look now?
Thanks.
-rm-


Re: use module only if it exists

2004-07-13 Thread Ramon Chavez
Hi.
This may be not a high enlightened answer but has solved me some time
looking for an answer to a question like yours:


my $IMAGE_SIZE=eval{require Image::Size};
...
if ($IMAGE_SIZE) {
   ### Some code
   ### Runs only if Image::Size is installed
}else{
   ### More code
   ### Runs if it's not installed
}


HTH

-rm-


- Original Message - 
From: perl.org [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 13, 2004 12:39 PM
Subject: use module only if it exists


 I want my code to call some subroutines in a custom module only if that
module
 exists on the system.  I can think of at least three techniques to
determine
 if the module exists: scan @INC, use UNIVERSAL::can (not sure that would
 work), or put the code in an eval block.  What is the best solution?  I
think
 an eval block sounds right, but I'm not sure.  My guess would look
something like:

 eval
 {
   use module;
   module::subroutine();
 };

 But the use statement of course throws a compiler error, so I think the
 appropriate thing is to put this code into a string and eval that.  But
this
 code is going to get replicated to a large number of files and I want the
 shortest syntax possible, or if there is some better way...

 TIA,

-John




 -- 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 http://learn.perl.org/ http://learn.perl.org/first-response




-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: Help on permissions for CGI

2004-06-29 Thread Ramon Chavez
First.
Sorry for the name.
I had the Outlook Express configured that way.

Second
Thanks, I had the idea that problem was new.
I'll check it with the service provider before attemping to use the
.httaccess

Thanks again.

-rm-
- Original Message - 
From: Gunnar Hjalmarsson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 29, 2004 2:36 PM
Subject: Re: Help on permissions for CGI


 Webmaster wrote:
  I am on a new server and have discovered the Directories in the
  CGI-BIN are visible to everybody.

 Your question is very much off topic. This list is for Perl, not for
 configuration of web servers.

 My first advice would be to leave the server for a sensibly configured
 one.

  This is, if a type www.mysite.com/cgi-bin  I get a list of all the
  files and subdirectories, and so for every subdirectory.
 
  I had never had this issue.
 
  What is the best permission for my directories?

 Ask your hosting provider.

  The other way would be to place an index.html file in every
  directory causein the files not to get listed, but I'm sure there's
  a correct way to do it.

 There are better ways, and the natural thing to do is asking your
 provider to fix it. For the case it's an Apache web server, you might
 be able to prevent indexing by uploading an .htaccess file to your
 cgi-bin with the applicable directive. See the Apache documentation.

 -- 
 Gunnar Hjalmarsson
 Email: http://www.gunnar.cc/cgi-bin/contact.pl

 -- 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 http://learn.perl.org/ http://learn.perl.org/first-response




-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Re: SSI in subdomains

2003-09-26 Thread Ramon Chavez
Shaun:

Thank you.

I tried with

   !--#exec cmd='perl /absolute/path/to/domain.com/cgi-bin/script.pl' --

And it worked

Answering some things. I'm hosting on a Cobalt server in Linux.

I got no differences using or not the spacebefore --. Anyway It's now in
the script.

As I said, the only way I was getting the SSI to work was having 'script.pl'
inside the 'cgi-bin' and inside the new 'cgi-bin' in the subdomain. Weird
isn't it??.

If I erased 'domain.com/cgi-bin/script.pl' there was a 'Permission denied'
message
If I erased 'domain.com/subdomain/cgi-bin/script.pl' there was a
'path/to/script.pl not found' message

If I used the absolute path to any of both files there was a message: 'an
error ocurred while processing this directive'

On the other hand, my only compliant with Shaun method is that, being as a
command line request I get the 'Content-type: text/html' hedaer in the
output, and this makes (at least now) not possible for me to use the same
scripts for the subdomain SSI than for direct access links.

I'll have to rewrite special scripts for SSI calling from sibdomain,
removing the headers. But that's better than keep getting errors.

Any comments?

 I get an error message, saying something like:
'Can't locate file path-to/domain.com/subdomain/cgi-bin/script.pl'

 I have tried both ways:

 !--#include virtual=/cgi-bin/script.pl--
 !--#exec cgi=/cgi-bin/script.pl--

 and haven't worked. I'm using '/' before cgi-bin to send the command to
the
 root, but still get the same message

I apologise in advance if I misunderstand your question, but here's my
college
try fwiw.

#1. what platform/httpd? .. (I'll assume Unix/Apache) .. Have you tried
emailing the Apache httpd mailing list?

#2. My experience with doing this is fairly extensive, since I do this alot,
albeit on my own OpenBSD web-server right under my desk (thus I am the
admin).

Here's my take on it. SSI are relative to the server path, not the http
path,
so anything starting with a / is pointing to the root filesystem on the
server
(or chroot environment). My usual MO with this is to not worry about
executable
bits and whatnot. Instead I use an SSI such as follows...

 !--#exec cmd='perl ./relative/path/to/script.pl' --

or...

 !--#exec cmd='perl /absolute/path/to/script.pl' --

which in your case would probably be...

 !--#exec cmd='perl ./cgi-bin/script.pl' --

*notice the space before the closing -- !!

Anyway, this has always worked like a charm for me, and since this way I
don't
have to set the executable bits on my script, it avoids some common security
issues aswell. Though do keep in mind that the .pl is still recieving the
GET method QUERY_STRING from the .shtml. Of course it would depend on the
setup provided by your hosting service. I am my ISP, so shrug I have free
rein within the limits of good sense.

Btw, doing it this way you can even pass variables to the script as
follow...

 !--#exec cmd='perl script.pl var1 var2 var3 ...' --

--
=
 Shaun Fryer
=
 http://sourcery.ca/
 ph: 905-529-0591
=

Science is like sex: occasionally something useful
comes out of it, but that's not why we do it.
-: Richard Feynmann


- Original Message -
From: Shaun Fryer [EMAIL PROTECTED]
To: Ramon Chavez [EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 3:58 PM
Subject: Re: SSI in subdomains




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



SSI in subdomains

2003-09-25 Thread Ramon Chavez
Hello all.

I have a problem.
I have subdomain and want to include some SSI in the webpages, but it
doesn't seem to work

I have this:
subdomain.domain.com

 that is actually stored in
domain.com/subdomain/

If I try to run a SSI from an HTML file calling a script from the cgi-bin,
say
subdomain.domain.com/index.shtml

I get an error message, saying something like:
   'Can't locate file path-to/domain.com/subdomain/cgi-bin/script.pl'

I have tried both ways:

!--#include virtual=/cgi-bin/script.pl--
!--#exec cgi=/cgi-bin/script.pl--

and haven't worked. I'm using '/' before cgi-bin to send the command to the
root, but still get the same message

So, I decided to create a cgi-bin directory in 'domain.com/subdomain/' and
uploaded the script there.

Now. If I run the script as
   www.domain.com/subdomain/cgi-bin/script.pl

Everything runs fine
But if I run it as
 subdomain.domain.com/cgi-bin/script.pl
It doesn't work and sends a Permission denied message

This way I can run
domain.com/subdomain/index.shtml

and get the correct answer. But I can't run
subdomain.domain.com/index.shtml

Which is bad because my reason to have the subdomain is to get people there
instead of going through www.domain.com.


The only way I have found to make subdomain.domain.com/index.shtml to work
is to have a copy of script.pl in both directories:
domain.com/cgi-bin
domain.com/subdomain/cgi-bin

wich seems absurd to me. Specially if this script is supposed to wite to a
file in the same directory.

How can I make a SSI call work from a subdomain???
Am I missing something???
Can you help me???

Any comment will be appreciated.

-rm-









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



Re: Cookies

2003-09-23 Thread Ramon Chavez
I'm not a guru... ;-P
But I was in a similar situation some months ago.

First of all I would tell Alejandro not to send Username-Password with the
cookie, but a Session ID, but I arrived late.

There are two modules (at least I only know them) to handle sessions with
cookies. Apache::Session and CGI::Session
Even been them complete solutions (I think so, I haven't really used them),
not all systems support them, that's my case, my web host doesn't has any of
them installed (That's because I haven't used them).

My suggestion is to create sessions, using cookies and generating the ID as
described in the previous message (not mine). But in Alex situation he might
want to give access only to the Administrator, wich makes things easier.

I am not sure right now, but I believe that I found useful hints in an
online course, from Ovid

Check this link
http://users.easystreet.com/ovid/cgi_course/

-rm-
- Original Message -
From: Wiggins d'Anconia [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Saturday, September 20, 2003 10:24 AM
Subject: Re: Cookies


 Alejandro Chavarria - CyPage wrote:
  Thanks for your reply Wiggins d'Anconia.  I understand the part about
just
  setting the cookie to an empty value, but I don't understand the part
about
  the secret key and a check failing.  Could you explain further?  When
would
  this happen: initially setting the cookie's value, or everytime you
check
  the cookie to see if the username and password are correct?
 

 Remember to group reply so everyone can help and be helped.  Essentially
 you would take the username and password once, at that time you create a
 hashed value of some user information such as an id # or the username if
 you want, etc. and any other information you want, IP and expiration
 time, plus a secret key, basically any phrase that your site knows
 that no one else does. (insert rant about how that is not secure because
 anyone with access to the code can see it, blah blah blah...) and you
 hash the values together (check out Digest::MD5 or Digest:SHA1 for two
 good hashing modules, I prefer the second for other reasons). Then each
 time you want to verify the user is who they say they are you take the
 information they provide (aka their username or id as mentioned above)
 and the hash you generated above which can be stored in teh same cookie
 and then you create the hash in the same manner as before and check to
 see that the hashes match.  (There is a much better explanation on this
 with code samples in the O'Reilly Apache Modules with Perl and C book.)

 It is *very difficult* (nothing is completely secure) for the user to
 create a hash that will be authentic based only on the knowledge they
 have, aka what the cookie looks like and what their user id is. They
 could guess that you are using a hash of something fairly easily, and
 that if their user id is 245 that there is probably user ids 1-244 but
 they can't guess your secret passphrase so to recreate a hash is nearly
 impossible.

 This also prevents the need to be passing the username/password around
 other than on initial login, and is much better than simply setting a
 single cookie and checking for its existence for obvious reasons.

 Examples:

 #
 #  Method to generate authentication cookie
 #
 use Digest::SHA1;
 sub authentication_string {
  my $self = shift;


  my $uid = $self-id;
  my $time = time;
  my $expires = 2592000;


  my $data = join(':', CONFIG_AUTH_KEY, $time, $expires, $uid);
  my $hash = Digest::SHA1::sha1_hex($data);


  return uid=$uid time=$time expires=$expires hash=$hash;
 }


 The above code assumes a 'User' object with an instance method of 'id'
 that returns the user's id, and a constant CONFIG_AUTH_KEY that contains
 the site's secret key.

 I leave the method for validating the authentication to the reader
 (mostly because mine has lots of non-standard error checking in it).

 Thoughts/comments from any of the gurus?

 http://danconia.org


 
  -Original Message-
  From: Wiggins d'Anconia [mailto:[EMAIL PROTECTED]
  Sent: Thursday, September 18, 2003 6:17 AM
  To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Subject: RE: Cookies
 
 
 
  
  On Wed, 17 Sep 2003 20:33:00 -0800, Alejandro Chavarria - CyPage
  [EMAIL PROTECTED] wrote:
 
 
 Hey,
 
 I have a script and I want to allow an administrator log on to it.  Once
 logged in they can change things... etc.  Basically stuff I don't want
 
  other
 
 people to be able to do.  I have decided that cookies is the best way to
 
  go.
 
 I've been looking and looking on the internet for a way to add a
logout
 button in the script that will delete the cookie that has the username
and
 password so they are essentially logged out.  I have read that you can
 
  fill
 
 in the expires field in with 1. a date in the past (ie. -1d) or 2. the
 word now.  I have heard about problems with both these methods.
 
 What do you 

Re: disable back button

2003-08-22 Thread Ramon Chavez
A page with no cache is awful.

Tell me I can't use the back button on your site and I won't visit it.


Bad idea to disable back button.

-rm-
- Original Message -
From: Octavian Rasnita [EMAIL PROTECTED]
To: Catriona Wordsworth [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2003 4:58 AM
Subject: Re: disable back button


 You cannot disable the back button and the keyboard hotkey for this task
 from a perl script.
 You might need to use a client side program, like a Javascript one.

 However, you can make a page not to cache, and to expire immidiately, and
 this way if a visitor will press the back button the page won't be shown
 automaticly.
 However, they will be asked if they want to resend the data to the server
 and if the visitors will answer 'yes', the browser will resend it with no
 problem.
 You need to use this method, and also check on the server that the data
was
 not submitted for a second time.

 To print the http headers for not allowing caching and to set the
expiration
 date to immidiately expire, use something like:

 print EOF;
 Content-type: text/html
 Cache-control: no-cache
 Pragma: no-cache
 Expires: Thu, 01-Jan-2033 01:01:01 GMT

 htmlhead
 ...
 /html
 EOF

 teddy.fcc.ro
 [EMAIL PROTECTED]
 - Original Message -
 From: Catriona Wordsworth [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, August 20, 2003 7:38 AM
 Subject: disable back button


 Hi guys,

 pretty simple stuff I hope, but can someone tell me how to disable the
back
 button in my perl script?

 thanks  regards

 Cat



 --
 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: Thumb-nailing Pic's

2003-07-30 Thread Ramon Chavez
The technique I described is useful only if you don't care what part of the
image is being thrown away. In my case it doesn't matter too much. I mean,
it doesn't really affect to me.

But. Let's just say you have horizontal and vertical images taken with you
digital camera (in my case), and you hae your thumbnails set to width=100
and height=85. With the horizontal ones there's no problem, but with
vertical ones you can be not fully satisfied with the results. In this case
Express Thumbnail Creator cuts the Thumbnail from the center.
That can be annoying for someone who wants to show a person, ha ha ha, you
may get someone headless.

Randall is right in this case. Fortunatelly for me this is not the case.(I
believe so, I'll need to check back my galleries ;-) )

The main advantage I have found this way is I can use a mmm... 'frame', for
the thumbnails, and I hadn't to worry for it to fix in a vertical or
horizontal thumbnail. www.sistemedic.com/cgi-bin/gals/phtls_imgs.pl

Anyway, it works for me, and it may work for other. I'm sure there are other
different ways to do it, and some of them will be much better. So I'll keep
trying new ways.

About ImageMagik, last tiem I visited the site I read it was commercial.
Maybe I was wrong. I need to go back and check, thanks for the advise.
However, I worked on my galleries trying to make them the less
Module-Dependant possible, at least with non common Modules. I was thinking
in making my script available someday.


Thanks Randal

-
I need to say it in case somebody visits my gallery. The script was
originally written by Mike Wheeler, I modified it to give it some extra
features.
---
-rm-



- Original Message -
From: Randal L. Schwartz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 30, 2003 9:25 AM
Subject: Re: Thumb-nailing Pic's


  Ramon == Ramon Chavez [EMAIL PROTECTED] writes:

 Ramon I meant that this program cuts rectangles from the original
 Ramon images, all of them with the same proportions. Like if you were
 Ramon cutting cookies from the paste for baking (lol). It then
 Ramon resizes all the resulting images to fit your thumbnail size.

 Ramon You're right. There's some info left out, but I believe it's
 Ramon better than deforming.

 I've found that technique to be less useful.  It really takes a human
 to understand what part of an image can be thrown away.  Simply
 scaling the image proportionally so that the maximum dimension is less
 than your space seems to be better.

 Ramon I was about to try ImageMagik, but I found it's commercial, and I
don't
 Ramon think my application is worth of it.

 No.  ImageMagick is clearly not commercial.  Where did you see that?

 --
 Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
0095
 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
 See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl
training!

 --
 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: Thumb-nailing Pic's

2003-07-29 Thread Ramon Chavez
Mmm.

Maybe I misspelled something.

I meant that this program cuts rectangles from the original images, all of
them with the same proportions. Like if you were cutting cookies from the
paste for baking (lol). It then resizes all the resulting images to fit your
thumbnail size.

You're right. There's some info left out, but I believe it's better than
deforming.

I was about to try ImageMagik, but I found it's commercial, and I don't
think my application is worth of it.

HAND.

-rm-


- Original Message -
From: Randal L. Schwartz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, July 28, 2003 10:45 PM
Subject: Re: Thumb-nailing Pic's


  Ramon == Ramon Chavez [EMAIL PROTECTED] writes:

 Ramon I have found useful for making thumbnails of the same size,
 Ramon regardless of the original size, the program Express Thumbnail
 Ramon Creator, from Express Soft (theres is a full working demo
 Ramon version). It doesn't matter the dimensions of your images, it
 Ramon can crop all the thumbnails to the same size, without
 Ramon deformation.

 If they're all the same size, you either have to deform, leave out
 info, or have some blank area.  You can't skip all three.  Which of the
 other two does it do then?

 ImageMagick's

 mogrify -geometry 100x100 *.jpg

 does a fair job of making a bunch of images that have 100 as their maximum
 dimension, scaling equally in both dimensions.

 You can do the same thing with PerlMagick *if* you can get PerlMagick
 to run.

 --
 Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
0095
 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
 See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl
training!

 --
 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: Thumb-nailing Pic's

2003-07-28 Thread Ramon Chavez
You are all right and I agree with you.

I was answering the original message, wich asks how to show all the images the same 
size regardless of the original size.
I really prefeer to use true thumbnails, because of the size (in bytes). 

Talking about dumbnails.
Agreeing with 'zentara', the disadvantage of this method is that you need to load the 
entire image, making the page slower (assuming you are loading an index page for 
images).
I  have found useful for making thumbnails of the same size, regardless of the 
original size, the program Express Thumbnail Creator, from Express Soft (theres is a 
full working demo version). It doesn't matter the dimensions of your images, it can 
crop all the thumbnails to the same size, without deformation.

I use it here, http://www.sistemedic.com/cgi-bin/gals/phtls_imgs.pl


-rm-

zentara [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED]
 On Fri, 25 Jul 2003 07:57:32 -0500, [EMAIL PROTECTED] (Ramon
 Chavez) wrote:
 
 Maybe I'm missing something here but, It can be done just using HTML, say...
 
 $h= 250;
 $w= 250;
 
 print img src=\yourimage.jpg\ width=\$w\ height=\$h\\n;
 
 Or maybe you're talking about something more complex and at this time in the
 morning I can't figure out what is it... ;-)
 
 A problem with your html method is that you still need to download
 the original big file to display the thumbnail. One  purpose of
 thumbnails is to speed up the download time, so you want real smaller
 thumbnail files.
 
 
 
 
 
 -- 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


Re: Thumb-nailing Pic's

2003-07-25 Thread Ramon Chavez
Maybe I'm missing something here but, It can be done just using HTML, say...

$h= 250;
$w= 250;

print img src=\yourimage.jpg\ width=\$w\ height=\$h\\n;

Or maybe you're talking about something more complex and at this time in the
morning I can't figure out what is it... ;-)
-rm-


- Original Message -
From: Support [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 24, 2003 11:50 PM
Subject: Thumb-nailing Pic's


 Hi All
 I'm using perl to write a html page on the fly which includes photos of
 different sizes. Does anyone know of a bit of code that I can add to my
 script that ensures the resulting page shows the pictures  on the page all
 the same size regardless of the original picture size.
 Cheer
 Colin

 --
-
 www.rentmyplace.co.nz
 The ultimate in that holiday spot away from the maddening crowd
 Join as a member today its FREE
 List your holiday accommodation for FREE
 --
--








 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.502 / Virus Database: 300 - Release Date: 18/07/2003








 --
 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: File uploading

2003-07-18 Thread Ramon Chavez
Hello.

CGI.pm module can restrict the size of the file being uploaded.
You canb use something like this:

my $max_size = 512000; #For 500kb limit

$CGI::POST_MAX=$max_size;

If the file size is bigger than that, it stop the process and returns an
error message.


But, thinking about it now, it's better to know the size of the file and
don't even waste time trying to upload it if it's too big, than begin the
upload and finish it if you get to the limit.

It may be a good idea to use the -s flag as 'awarsd' said to decide if
begining the upload process, but keep CGI::POST_MAX for security reasons.

-rm-


- Original Message -
From: Mike Harrison [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 17, 2003 9:03 PM
Subject: File uploading


 Hello,

 I have a perl program that allows a user to upload a file (either .jpg or
 .gif) to the server, and returns a message if it exceeds a specified size
 (in my case 100kB).  Currently (and don't laugh - I am new to perl), I go
 through the motions of uploading the file in 1024-byte blocks (in binary
 mode), and increment a counter with each block.  If the counter exceeds
100
 (i.e. greater than 100kB), then it exits the loop, displays a warning
 message and deletes the file.

 I am sure there would have to be an easier and more efficient way of doing
 this - that is, somehow finding out how large the file is without having
to
 download it first.

 Does perl have a module that can check the size of the file?  And for that
 matter, its type (.jpg, .gif etc.)?

 Thanks in advance,
 Mike.




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



Re: File uploading

2003-07-18 Thread Ramon Chavez
Hello.

CGI.pm module can restrict the size of the file being uploaded.
You canb use something like this:

my $max_size = 512000; #For 500kb limit

$CGI::POST_MAX=$max_size;

If the file size is bigger than that, it stop the process and returns an
error message.


But, thinking about it now, it's better to know the size of the file and
don't even waste time trying to upload it if it's too big, than begin the
upload and finish it if you get to the limit.

It may be a good idea to use the -s flag as 'awarsd' said to decide if
begining the upload process, but keep CGI::POST_MAX for security reasons.

-rm-


- Original Message -
From: Mike Harrison [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 17, 2003 9:03 PM
Subject: File uploading


 Hello,

 I have a perl program that allows a user to upload a file (either .jpg or
 .gif) to the server, and returns a message if it exceeds a specified size
 (in my case 100kB).  Currently (and don't laugh - I am new to perl), I go
 through the motions of uploading the file in 1024-byte blocks (in binary
 mode), and increment a counter with each block.  If the counter exceeds
100
 (i.e. greater than 100kB), then it exits the loop, displays a warning
 message and deletes the file.

 I am sure there would have to be an easier and more efficient way of doing
 this - that is, somehow finding out how large the file is without having
to
 download it first.

 Does perl have a module that can check the size of the file?  And for that
 matter, its type (.jpg, .gif etc.)?

 Thanks in advance,
 Mike.




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



Re: http authentication via perl CGI script?

2003-07-15 Thread Ramon Chavez
Hello.

Don't know if it will be useful to you, but you can try CGI::Session or
Apache::Session modules
I read some about in www.cpan.org and found them very useful.

They create cookies to maintain a user's session. Users need to authenticate
via username and password. After that you can use the cookie for allowing
access on your site.
I personally haven't used them because my host doesn't support those
modules, but what I have read seems very nice.

-rm-
- Original Message -
From: Yannick Warnier [EMAIL PROTECTED]
To: perl beginners list [EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 10:50 AM
Subject: http authentication via perl CGI script?


 Hi all,

 I'm having a hard time finding how an http authentication works and how
 it could be used with a file containing the logins and pass I want the
 user's entry to be compared to.

 So in more details the present situation is:
 - I have a file containing the logins and pass from some users
 - I have a perl CGI script looking if there is a certain cookie
   - if the cookie is there I can display the web page
   - if the cookie is not there I pop up a 401 and ask the user for login
 and pass

 And I want to get those login and pass the user enters and check them
 with the contents of my file. I read somewhere there was no way to get
 the password, but I am able to get it using php (with the
 $HTTP_AUTH_PASSW var). So I'm confused...

 Is there any nice location where I can learn more about this or a
 general solution (I would be pleased not to use a separate form to get
 the user's login and pass but I think I will do that while not finding a
 solution).

 Thanks all,

 Yannick


 --
 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: cookie expiration time problem

2003-07-11 Thread Ramon Chavez
I'm not so experience using cookies with cgi but.

have you ever tried using single quotes??

'+4h'

Hope it helps.

-rm-

- Original Message -
From: Sawsan Sarandah [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, July 11, 2003 3:13 PM
Subject: cookie expiration time problem


 Greetings,

 I have a small problem. When I create a cookie using cgi.pm, the
expiration
 date is always three hours behind the actual time. In other words, the
 following code snipet:

 # Time on my local machine: 10:00 pm
 # Rhat Linux server using date command: Fri Jul 11 21:59:44 IDT 2003
 # hwclock command: Fri 11 Jul 2003 09:59:48 PM IDT  0.611152 seconds

   $cookie = $cgi-cookie

  -name= $cookiename,
  -value= $uname,
  -expires= +4h,
  -path='/'
 );

 The above code produced a cookie with an expiration time as follows:

 Expires:  Fri, Jul 11 2003 22:58:33

 Notice that the cookie expires in one hour, not in four hours (+4h). What
 could possibly be the problem? Where is PERL reading the incorrect time
 from?

 Thank you.


 --
 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]



Better way to upload??

2003-07-08 Thread Ramon Chavez
Hi all.

I need some advice on this.

I'm writing a script for uploading a file ($file). Saving it as
$file_path/$name

The way I'm doing this right now is (after checking the file extensión and
assuring every character is only a letter or an underscore):

-My way
open(LOCAL, $file_path/$name) or die $!;
   while($file) {
  print LOCAL $_;
   }
--


But I have found this other way to do it:
-Other way--
open (LOCAL,$file_path/$name) or die $!;
  while ($bytesread=read($file,$buffer,1024)) {
  print LOCAL $buffer;
  }
-

The 'Other way' helps to handle the size of the file been uploaded, but I'm
using CGI.pm for doing that, resticting the size.

I really don't know wich of them both is better. Or what are the main
advantages (or disadvantages) for each one. I have tried my script with many
files (Images in my case) and I have set some security controls to prevent
uploading other than images files, but really can't figure where could the
main advantege be in these two pieces of code.

Can you all folks give me some comments on this??.

Maybe I'm losing something and there's an even better way to do it.

Your help is very appreciated
-rm-


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



Fw: Better way to upload??

2003-07-08 Thread Ramon Chavez



 You are right Dan ;-)

 The 'Other way' desn't really handle te size. I'm sorry for that. What I
was
 really thinking is that you can have a control of what amount of data is
 being uploaded just counting the loops (1 Kb for every loop).
 -rm-
 - Original Message -
 From: Dan Muey [EMAIL PROTECTED]
 To: Ramon Chavez [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Sent: Tuesday, July 08, 2003 2:14 PM
 Subject: RE: Better way to upload??


  Hi all.

 Howdy

 
  I need some advice on this.
 
  I'm writing a script for uploading a file ($file). Saving it
  as $file_path/$name
 
  The way I'm doing this right now is (after checking the file
  extensión and assuring every character is only a letter or an
  underscore):
 
  -My way
  open(LOCAL, $file_path/$name) or die $!;
 while($file) {
print LOCAL $_;
 }
  --
 
 
  But I have found this other way to do it:
  -Other way--
  open (LOCAL,$file_path/$name) or die $!;
while ($bytesread=read($file,$buffer,1024)) {
print LOCAL $buffer;
}
  -
 
  The 'Other way' helps to handle the size of the file been
  uploaded, but I'm using CGI.pm for doing that, resticting the size.\

 Th Other way doesn't handle the size of the file being uploaded it helps
 write it in smaller chunks.
 CGI.pm will let you restrict the file to a certain size but the Other way
 writes
 To the new file in smaller chunks no matter if the uploaded file is 1K or
 1Mb.

 Now that we have that all sorted not sure exactly what the pros and cons of
 each are as I don't do to much file uploading. But the small amount I do is
 pretty much your Other way method.

 HTH

 DMuey

 
  I really don't know wich of them both is better. Or what are
  the main advantages (or disadvantages) for each one. I have
  tried my script with many files (Images in my case) and I
  have set some security controls to prevent uploading other
  than images files, but really can't figure where could the
  main advantege be in these two pieces of code.
 
  Can you all folks give me some comments on this??.
 
  Maybe I'm losing something and there's an even better way to do it.
 
  Your help is very appreciated
  -rm-
 
 
  --
  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]