perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Wesemann <f.wesem...@fotofinder.net>
Subject Re: Issue with getting Apache to pass %ENV to sub-scripts on Apache2/mod_perl2
Date Fri, 30 Jul 2010 09:47:56 GMT
Robby Desmond schrieb:
> To answer my own question (thanks to the help of our programmer here),
> the issue is with the way Embperl.pm attempts to read parameters from a
> CGI object.
>
> Embperl.pm lines 320-22:
>
>         # the param_fetch needs CGI.pm 2.43
>         #$params = $cgi->param_fetch( $_ ) ;
>         $params = $cgi->{$_} ;
>
>
>   
This was a known issue
http://www.gossamer-threads.com/lists/modperl/embperl/98672?search_string=CGI.pm
and has been fixed in Embperl 2.4

> In fact, that older method will not work (and is not documented to work)
> for CGI any more. The commented out method is the one that works for CGI
> 3.49.
>
> Our form now works.
>
> -R
>
> On 7/29/2010 12:55 PM, Robby Desmond wrote:
>   
>> Hi all,
>>
>> Sorry, but I have to amend this question. It appears that the ENV is
>> being passed just fine.
>>
>> The issue is that Embperl is not parsing the form data when it is not
>> URL-encoded. (Some of the form data includes the book id of the files
>> being uploaded, and must be included for the "are you authorized" to
>> work correctly.)
>>
>> Why would Embperl code not be properly interpreting mutlipart/form-data?
>>
>> -R
>>
>> On 7/29/2010 10:04 AM, Robby Desmond wrote:
>>     
>>> Hi,
>>>
>>> When testing our server (RHEL 5, x86_64, Apache 2.2.3, mod_perl2,
>>> Embperl 2.3.0), we had no virtual hosts defined (testing was done on the
>>> raw hostname) and all of our forms seemed to work fine.
>>>
>>> Now that we have gone to a NamedVirtualHost configuration (because in
>>> production this server answers to many domains), we have run into an
>>> issue with some of our forms. For the most part, changing the encoding
>>> to "application/x-www-form-urlencoded" has solved our problems.
>>>
>>> However, the one form that *has* to be "multipart/form-data" now cannot
>>> seem to pull in the $ENV{REMOTE_USER} variable from Apache.
>>>
>>> It is a file-upload form, and goes through 3 stages, all run by calling
>>> back to itself and Execute-ing a different Embperl page based on which
>>> stage it is at.
>>> 1) Query user about *what* is being uploaded (add_files_1)
>>> 2) Gather file metadata (add_files_2)
>>> 3) Upload files (and inform user of successful upload when they finish)
>>> (add_files_3)
>>>
>>> The code looks like this:
>>> <form name="Add_Files" method="post" action="bv.add_files.epl"
>>> enctype="multipart/form-data" style="display: inline;">
>>>   [# execute the appropriate page #]
>>>   [$ if $fdat{Add_Files_3} $]
>>>     [- Execute('lower/bv.add_files_3.epl'); -]
>>>   [$ elsif $fdat{Add_Files_2} $]
>>>     [- Execute('lower/bv.add_files_2.epl'); -]
>>>   [$ else $] [# go to the starting page #]
>>>     [- Execute('lower/bv.add_files_1.epl'); -]
>>>   [$ endif $]
>>> </form>
>>>
>>> At the moment, if we change the encoding to x-www-form-urlencode, we can
>>> get through steps 1 and 2 without losing the $ENV{REMOTE_USER} variable.
>>> However, as you might expect, step 3 won't work that way.
>>>
>>> If any part of the form is set to "multipart/form-data", the Embperl
>>> scripts cannot read the ENV variable and give our "Not allowed to view
>>> this" page.
>>>
>>> Authentication exists in this set of directories, and ExecCGI has been
>>> added explicitly to these directories both in the main configuration and
>>> in the vhost.
>>>
>>> Additionally, the configuration directives for Embperl exist in both the
>>> main server configuration and in the vhost.
>>>
>>> Am I missing something about the transition to Apache2/mod_perl2 that
>>> alters what ENV information is passed from instance to instace of an
>>> Embperl page?
>>>
>>> Any ideas would be most helpful.
>>>
>>> -R
>>>
>>>       
>>     
>
>
>   


-- 
mit freundlichem Gruß,

Frank Wesemann
Fotofinder GmbH         USt-IdNr. DE812854514
Software Entwicklung    Web: http://www.fotofinder.com/
Potsdamer Str. 96       Tel: +49 30 25 79 28 90
10785 Berlin            Fax: +49 30 25 79 28 999

Sitz: Berlin
Amtsgericht Berlin Charlottenburg (HRB 73099)
Geschäftsführer: Ali Paczensky




Mime
View raw message