Re: Multiple script tags in HTML head

[Richard J. Barbalace]

> Is there any way to get multiple script tags using CGI.pm, or do I
> need to abandon it?

Ah, upon a closer reading of the documentation, I found the answer.

-script => [
{
 -language => 'JavaScript',
 -src  => '/javascript/foo.js',
},
{
 -language => 'JavaScript',
 -src  => '/javascript/bar.js',
},
       ],

Thanks to anyone who started to look at this.
+ Richard J. Barbalace
  [EMAIL PROTECTED]


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

Multiple script tags in HTML head

[Richard J. Barbalace]

Hi.

I'm trying to use CGI.pm to include multiple script tags in a web page.

I have code like the following:
$html .= header();
$html .= start_html(
-script => {
-language => 'JavaScript',
-src  => [
  '/javascript/foo.js',
  '/javascript/bar.js',
 ]
},
   );
$html .= 'Body goes here.';
$html .= $query->end_html();

In the HTML head, this prints out:


Instead of:



With only one of the javascript sources, I correctly get:


Is there any way to get multiple script tags using CGI.pm, or do I
need to abandon it?  The same question applies to multiple style
sheets.

+ Richard J. Barbalace
  [EMAIL PROTECTED]


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

Re: Crypt function

[Richard J. Barbalace]

Randal L. Schwartz <[EMAIL PROTECTED]> writes:
> my $encrypted = crypt($cleartext, "zz");
> .
> As for that salt parameter, ignore it.  I just use "zz" or something.
> In this day and age with fastcrypt implementations, having a varying
> salt really doesn't add much to security.

Having a better salt (the two characters "zz") helps prevent casual or
accidental browsing (say, by the sysadmin) from revealing that two
users have the same password.  While this only adds minimal security,
it's worth the minimal effort to avoid that problem.  You can use the
first (or last) two characters of the username for a simple salt:
  my $encrypted = crypt($cleartext, substr($username, -2, 2));

The brief documentation for crypt is available (among other places) at:
http://www.perl.com/pub/doc/manual/html/pod/perlfunc/crypt.html

[EMAIL PROTECTED] adds:
> I normally use Digest::MD5 for this kind of thing.  The module, like most
> others, is available from CPAN.
> 
> #!/usr/bin/perl -w
> 
> use Digest::MD5 qw(md5_hex);
> use strict;
> 
> my $secret_password="foobarqux";
> my $digest=md5_hex($secret_password);
> 
> This is not really encryption as it's a one-way function.  You can't reverse
> the procedure to find the password from the digest so to authorise your users
> you will need to perform the digest function on the password they've supplied
> and compare it with the stored string.

I'll second this recommendation.  To avoid the same password issue
described above, it's slightly better to append the username when
computing the hash, as in:
  my $digest = md5_hex($secret_password . $username);

You may want to require a minimum password length or check for
"obvious" passwords.  Also, consider using SSL for the CGI script to
prevent the password from being sniffed during transmission to your
server.  Consult with a security expert if you need more than basic
security on your site.

+ Richard J. Barbalace

Re: Encrypting data on the server

[Richard J. Barbalace]

Mark Ross <[EMAIL PROTECTED]> writes:
> Here's my goal: To take information via a form, encrypt it with a duel key
> encryption, and then write that encrypted message to a text file for latter
> use. I also need to do this in such a way so that the server admin's can't
> read it (I work for a credit union, and regulations are stiff).

It's not clear to me what all your goals are.  Here are some questions
to ask:
1) Does anyone ever need to access the unencrypted data?  (Eg, if you
   are only trying to verify someone's identity, you might use a
   one-way hash and compare the encrypted hash in future
   transactions.)
2) If access to the unencrypted data is needed, when, where, and for
   what reason is it needed?
3) Who needs to access the unencrypted data?  The user submitting it
   only?  Certain personnel at your company?
4) Who must not access the unencrypted data?  Just the server admins?
   Everyone at your company?  Everyone elsewhere?
5) Where can encryption keys be reliably stored?  On the user's
   computer?  On another computer unavailable to the server admins?

> Do anyone have any advice on how I could go about encrypting the data? I've
> looked at PGP, and the various Perl modules, but the private key is coded
> into the script, and so admin's could get at the data.

Unless you don't need to decrypt the data (and use a one-way hash),
it's clear you can't store the encryption keys (at least not all of
them) on the server, since you don't want the server admins to have
access to them.  Beyond that, I can't make further suggestions without
knowing more.  This is really more of a security question than a perl
question, so I recommend that you consult a security expert regarding
your needs.  Doing security right can be hard, and you probably don't
want to do it wrong.

> I'm not sure that this is even possible :-(

Depending on what you need to do, it's probably possible, but make
sure it's done well.

+ Richard J. Barbalace