On Wed, 08 Dec 1999, Jason Simms wrote:
> If I use
> an internal redirect, I could avoid all this as the browser never "sees" the
> redirection, and thus my data would remain safe. But, I need to set a
> cookie at redirection as well.
What about this trick:
- make handler1 in your module do an
On 8 Dec 99, at 16:26, Vivek Khera wrote:
> Encryption, or store the state locally and pass a handle to that
> state, eg, a file name or database object number.
In order to do this security must be done. It is too easy for
someone to make a form and have it submit strange values to your
scrip
On Wed, 08 Dec 1999, Jason Simms wrote:
> Unfortunately, I am passing information to a legacy CGI script written
> before I came on board. It will be my task to rewrite this script, but not
> for a few months. Believe me, if I could use a custom module of my own, I
> would. Then I could use
The sensitive information comes from my Oracle database on the backend. I
could program the CGI script to get the information by only sending half
(say, the "key") through the URI and querying for the rest, but that, to me,
takes up potentially too many resources if there is a way that I can
> "JS" == Jason Simms <[EMAIL PROTECTED]> writes:
JS> if I could give the script access to the environment, I wouldn't need to
JS> pass the parameters over through the URI. Is there anohter way to do this?
Encryption, or store the state locally and pass a handle to that
state, eg, a file
You know, I had this same idea (more or less). Unfortunately, I am
concerned about the size of the flat file or the amount of memory it would
use. The reason is that this is for an unbelieveably high-session site. It
is safe to assume that this read/write would have to happen at least severa
Unfortunately, I am passing information to a legacy CGI script written
before I came on board. It will be my task to rewrite this script, but not
for a few months. Believe me, if I could use a custom module of my own, I
would. Then I could use pnotes() or any number of other tricks... *sigh
> Am I correct in assuming that
> an internal redirect does NOT have the ability to set a cookie?
Yes, that is correct. There may be a way for mod_perl to set the cookie
the CGI script will return, but that sounds like voodoo to me.
> The entire reason I have to do this is that I need to pass
Pass the user a cookie which contains a key to a session object.
Write the data to the session object using the cookie's key from your mod perl
process. Read back the session data using the key passed to you from the cookie
in the cgi process.
When you set the cookies PATH information, make sure
Where do you get that sensitive information from? If it is originated on your
own server then why can't CGI script get it without mod_perl? Or why can't
you do internal redirect and put that information into query string? It doesn't
go outside of your server anyway.
If it is coming from client ma
Jason,
If you don't *have* to use CGI scripts, you can stick the "sensitive" stuff
into $r->pnotes and do an internal redirect to another PerlHandler. The
browser would never see the sensitive info (it would be passed among handlers
on the server end), so this would go a long way to protecting th
Thanks for the advice, and this brings up another question... Honestly, if
I were using an internal redirect, I wouldn't need to bother with these
environment variables at all. The problem is that many times before I do
this redirect, I also need to set a cookie. Am I correct in assuming tha
> "JS" == Jason Simms <[EMAIL PROTECTED]> writes:
JS> I have a quick question... Let's say I have a module that sets some
JS> environment variables (in %ENV). This module then redirects to a CGI
JS> script. Is there any way that the CGI script can access these new
If you redirect, that
I have a quick question... Let's say I have a module that sets some
environment variables (in %ENV). This module then redirects to a CGI
script. Is there any way that the CGI script can access these new
environment variables? If I check for them in %ENV in the script, they have
disappeared
14 matches
Mail list logo
