keep the reference pointer of an object

[sam]

Hi,

I would like to do something like C in Perl. Sorry, I m not expert in Perl.
I m writng a webmin module that manage the Cyrus email accounts.
But every time when need to change the Cyrus user account info, I need
to use the Cyrus::IMAP::Admin->new() method login Cyrus first.

How can I login Cyrus once and keep its returned reference for another
..cgi file used? (I won't keep plaintext password in perl or
configuration file either, so if imap is not login by Cyrus admin, user
need to login Cyrus admin account first).

For example, if I have already invoked $imap = &imap_connect() in the
index.cgi file, another cgi file (set_quota.cgi) no need to call the
method imap_connect() again, instead, it will somehow use the reference
of imap created in the index.cgi file and just call $imap->setquota().

Not sure if use Global declaration is a good idea. I don't want this
reference to be "boardcast". I found command ENV is a way to get the
value of the enviornment variable, but don't think this is a secure way
to get the reference of the object in this case.

Thanks
Sam.

 

[Alan Mead]

How can I login Cyrus once and keep its returned reference for another
.cgi file used?
[...]
For example, if I have already invoked $imap = &imap_connect() in the
index.cgi file, another cgi file (set_quota.cgi) no need to call the
method imap_connect() again, instead, it will somehow use the reference
of imap created in the index.cgi file and just call $imap->setquota().

I don't have an answer but here's some information: Perl objects are
actually references (so that's not so different from C). The objects are
destroyed automatically when the reference goes out of scope.

So, I guess you need to create a scope that is shared between your
programs. I simple way to do that would be to have a single
program/module. In that case, you make a connection st the top of the
file outside of any closures and the reference can be shared by all the
rest of the code (more or less).

If you really want to break up the code into different files, then I
believe the technology you want is "inter process communication" and there
is an IPC package. Maybe that will help?

-Alan

 

[Matija Papec]

X-Ftn-To: sam

How can I login Cyrus once and keep its returned reference for another
.cgi file used? (I won't keep plaintext password in perl or
configuration file either, so if imap is not login by Cyrus admin, user
need to login Cyrus admin account first).

For example, if I have already invoked $imap = &imap_connect() in the
index.cgi file, another cgi file (set_quota.cgi) no need to call the
method imap_connect() again, instead, it will somehow use the reference
of imap created in the index.cgi file and just call $imap->setquota().

You can make your objects persistent with Data:umper or FreezeThaw but
their usability depend on the object class. If your object uses socket
handle, you might want to use some different approach.

http://search.cpan.org/~ilyaz/FreezeThaw-0.43/FreezeThaw.pm

 

[nobull]

[sorry if an earlier draft of this appears too, my ISP's NNTP spool
appears to be accepting posts but then they don't appear even in the
local spool ]

I would like to do something like C in Perl. Sorry, I m not expert in Perl.

OK so if you claim you know how you'd do it in C then ptray tell, how
would you make an in-memory object (including an open soocket
connection) persist from one instance of a CGI process to another if
you were writing your CGI programs in C?

Before you continue please recite 10 times "Perl is not CGI, CGI is
not Perl".

I m writng a webmin module that manage the Cyrus email accounts.
But every time when need to change the Cyrus user account info, I need
to use the Cyrus::IMAP::Admin->new() method login Cyrus first.

How can I login Cyrus once and keep its returned reference for
another .cgi file used?

In general you can't make in-memory entities in Perl persist from one
process to another unless they provide a means to serialise themselves
to a string/file. (This is the same as C and most other languages).

(I won't keep plaintext password in perl or configuration file either, so
if imap is not login by Cyrus admin, user need to login Cyrus admin
account first).

You want to maintain the Cyrus credentials as some sort of session
persitant data. There are three ways to maintain session data in web
programming (in the URL, in a hidden field, or in a cookie). You can
also use a small bit of session data stored using one of these three
to identify larger session data stored in a database or filesystem.

This is not specific to Perl or CGI - it applies to server-side web
programming in general and hense equally to other languages and other
ways of interacting with the web server.

For a example of implementing web sessions in Perl and CGI you could
do worse than look for a Perl module with 'CGI' and 'Session' in its
name.

For example, if I have already invoked $imap = &imap_connect() in
the index.cgi file,

You should not use the special &-prefixed subroutine call notation
unless you know what it does and want those semantics.

another cgi file (set_quota.cgi) no need to call the method
imap_connect() again, instead, it will somehow use the reference
of imap created in the index.cgi file and just call $imap->setquota().

As I said above, in general you can't make in-memory entities in C,
Perl and most other languages persist from one process to another.
(This is particularly true of entities that embody a connection to an
external resource).

Not sure if use Global declaration is a good idea. I don't want this
reference to be "boardcast". I found command ENV is a way to get the
value of the enviornment variable, but don't think this is a secure
way to get the reference of the object in this case.

Niether a global variable nor environment variable set in one CGI
process would propagate to another CGI process. And even if it did[1]
then it would not be per-session. Once one person had "logged in"
anyone anywhere could use the connection.

[1] As, say, they would if you replaced CGI with mod_perl using a
single Perl instance. (Not something you'd usually do).

 

[sam]

You want to maintain the Cyrus credentials as some sort of session
persitant data. There are three ways to maintain session data in web
programming (in the URL, in a hidden field, or in a cookie). You can
also use a small bit of session data stored using one of these three
to identify larger session data stored in a database or filesystem.

In this case I think I will keep the plaintext of the password as a
hidden field. Actually this is only my concern, I worried the password
will be somehow "seen" by the client. Is there any example I can follow
to make a hidden value to be passed around, and probbably with cookie to
be safer?

Thanks
Sam

 

[Tad McClellan]

(e-mail address removed) wrote:

In this case I think I will keep the plaintext of the password as a
hidden field.

You should realize that a "hidden" field is not really hidden...

Actually this is only my concern,

Good, but you haven't solved the problem yet, keep thinking about it.

I worried the password
will be somehow "seen" by the client.

View -> Page Source

then

Edit -> Find in Page (enter "hidden")

there is the password for all to see.


All that is "hidden" is the user interface corresponding to that
value, that is, a "normal" user that only knows how to point
and click cannot change its value. The value is easy to see
and easy to spoof, it is not a "security" mechanism, it is
a "state" mechanism.

You will still need to work out a way to handle the "security"
part of your problem.


(and we don't solve non-Perl problems in the Perl newsgroup.)



Did you follow that suggestion yet?

 

[gnari]

In this case I think I will keep the plaintext of the password as a
hidden field.

no please do not do that. keep a session key in your hidden field,
and keep the password in persistent session data.

Actually this is only my concern, I worried the password
will be somehow "seen" by the client.

hidden fields can easily be 'seen'

Is there any example I can follow
to make a hidden value to be passed around, and probbably with cookie to
be safer?

cookies are not safer, and only marginally more difficult to be 'seen'

good advice

gnari