Re: graphics in perl
Am Sonntag, 22. Juni 2008 11:27:26 schrieb Malka Cymbalista: > We are running perl 5.8.5 on a Linux machine that is running apache 2.2.6 > with mod_perl 2.0.3. Our data is in a MySQL database (MySQL 5.0.45) > > We have been asked to write a web application that requires plotting > capabilities. We do most of our web programming in perl so I am looking > for a perl module that has the following features: 1. ability to create > histograms > 2. ability to create x,y plots > 3. ability to zoom in on a portion of the graph > 4. ability to calculate the distance between 2 points on the graph > 5. ability to hover on a point and bring up some text > > Does anyone have any suggestions for which perl modules we should look > into? > > Thanks for any information. For drawing graphs you can have a look at google graph api (http://code.google.com/apis/chart/) I've once used another cart libray offering API in different languages see : http://www.advsofteng.com/product.html And then there is GD::Graph, but I have no experience with this. For basic graphic functions look at Imager (imager.perl.org) -- Regards Rolf Schaufelberger
Re: [MP2]: setting group for a request (require group ...)
Geoffrey, André,
Thank you for your answer.
Conclusion: I will have to:
. write my own PerlAuthzHandler
. define a new directive to define my group
Thanks again
2008/6/19 André Warnier <[EMAIL PROTECTED]>:
> Hi.
>
> I believe that the issue below is more in the way of thinking about this,
> than a real technical issue.
>
> You don't need to involve Apache in the group part.
> I don't think that Apache, per se, even has a field "group" in his internal
> Request structure.
> That is probably why you do not find any API to set or read it.
>
> Let my explain how I understand it :
>
> Authentication consists of finding out who the user is.
> To simplify, we could say that this consists of getting and verifying his
> user-id.
> But, at the same time, we could collect some additional attributes about
> him, like his email address, or a list of groups of which he is a member.
> The application /may/ want to authenticate users in order to (later) also
> authorise them or not to do something. But not necessarily; it could also
> be only for the purpose of logging who accessed the page.
>
> Anyway, now your Authentication module has done it's job, it has
> authenticated the user and saved his user-id. It does not really care what
> this user-id will be used for, that is not it's job.
>
> The module returns OK, and Apache continues.
>
> - end of authentication
>
> some time passes
>
> - start of authorization ---
>
> This consists of verifying if this resource that is requested can be
> returned, depending on some criteria.
> Usually, it will depend on the userid, or some characteristic of the user.
> But not necessarily : it could also depend on a secret key that is included
> in a cookie, for example (if the key is there, the resource is granted, and
> otherwise not).
> If this check is succesful, the authorization returns OK. If it is not, it
> returns not-OK.
>
> end of authorization ---
>
> Apache checks the return code. If it is OK, Apache serves the page. If it
> is not-OK, Apache returns a "forbidden" page.
>
> --- end of request ---
>
> Now, in your case, you want
> a) to authenticate the user
> b) later, to authorize access to a resource, in function of some
> characteristic of that user (is he member of one of the authorized groups)
>
> You have already done (a), with a PerlAuthenHandler, and you have stored
> the user-id in the request, so you can get at it later.
>
> If you add a PerlAuthzHandler for authorization, then what your handler has
> to do is :
>
> 1. find out which groups are authorized to access this resource.
> That could be by getting the contents of the "require" clause of the Apache
> configuration, or by getting the value of some "PerlSetVar" in the same
> section (e.g. PerlSetVar AuthorizedGroups "group1,group2")
> (in your module, you would get this value as
> $OKgroups = $r->dir_config("AuthorizedGroups");
>
> 2. find out if this userid (stored in the request) is a member of one of
> these groups.
> For that, you need some additional information about the user, not just his
> user-id. This you could do using a "group" file, like Apache does in it's
> Basic authentication scheme (AuthGroupFile ), and read it and parse it
> when you need to, and then compare the result to $OKgroups.
> But that would be inefficient.
>
> Since in (a) you are already accessing some information about the user (to
> verify his userid), I would at the same time collect information about which
> groups he belongs to, and save that somewhere in the Request object, for
> example with something like
> $r->pnotes('groups' => $groups);
>
> Then later, your module (b) can get it back, with
> $groups = $r->pnotes('groups');
> and compare this to the authorized groups.
>
> I hope this helps.
> André
>
>
>
> titetluc titetluc wrote:
>
>> Hello all,
>>
>> I am writing a mod_perl authentication module (My::Auth).
>>
>> This module sets the user using the Apache2::RequestRec::user method.
>>
>> package My::Auth;
>> sub {
>>
>> $r->user('getting the user in my module internal structure');
>> return OK;
>> }
>>
>> In the Apache configuration file, I can use the configuration
>>
>>
>> PerlAuthHandler My::Auth
>> Require user user1
>>
>>
>>
>> I would like to use my module in another configuration where group is
>> checked
>>
>>
>> PerlAuthHandler My::Auth
>> Require group group1
>>
>>
>>
>> I can not find any mod_perl API method (Apache2::RequestRec::group ?) to
>> set
>> the group. I only found Apache2::RequestRec::require method, but this
>> method
>> only read the require configuration.
>>
>> One way to solve the problem is the modify the My::Auth::handler method :
>>
>> package My::Auth;
>> sub {
>>
>> $r->user('getting the user in my module internal structure');
>> my $requires = $r->requires;
>>
>> # here the code to verify authorization
>>
>> return OK;
>> }
>>
>> but I think this is a workaround:
>> . My::Auth::handler is an AUTHENTICATION hand
Re: [MP2]: setting group for a request (require group ...)
titetluc titetluc wrote: Geoffrey, André, Thank you for your answer. Conclusion: I will have to: . write my own PerlAuthzHandler yes . define a new directive to define my group no - you can overload the Requires directive. the example I pointed you to shows you how: http://www.modperlcookbook.org/code/ch13/Cookbook/AuthzRole.pm if you return OK or AUTH_REQUIRED the configured httpd authz handler will not be run, leaving your PerlAuthzHandler in control of the authz phase. HTH --Geoff
Re: Apache 2 + perl UTF-8 problem
On Sun 22 Jun 2008, André Warnier wrote: > Now, the first thing I would like to understand is why this is so. > Since this is a POST, and since the browser knows that "everything" is > UTF-8, I would expect it to send the proper multipart POST, with each > item marked as UTF-8. So why does my cgi-bin script not see it as such ? Yes that is the current state. Neither CGI nor libapreq2 does that conversion for you, afaik. You have to do it yourself. > (I am trying to do that to see the content of the real POST, before > CGI.pm grabs it.) You could write a small mod_perl input filter. That's not complicated in your case. With luck one of the examples on perl.apache.org does fit your needs. Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
Re: Apache 2 + perl UTF-8 problem
André Warnier wrote:
Hi.
I apologise if this is not really a mod_perl problem, but this list
might be my best chance to find the competences required for some tips.
Platform : SunOS 5.8 (Solaris 8)
Apache : Apache/2.0.52
Perl : v5.8.5 built for sun4-solaris
CGI.pm : 3.37
That version of CGI.pm has support for what you need:
use CGI qw( -utf8 );
Although the documentation warns it will interfere with file uploads.
As an alternative, below is a customization I've been using that tries to keep
file uploads intact. It's been running live for almost 3 years now. The code
looks pretty similar to what's in CGI 3.37, so maybe that warning is just FUD.
I suggest you test either solution before believing me ;-)
Usage: Add it to your startup.pl, or add a "use CGI::as_utf;". It assumes you
always use the object interface.
Rhesa
package CGI::as_utf;
BEGIN
{
use strict;
use warnings;
use CGI;
use Encode;
{
no warnings 'redefine';
my $param_org = \&CGI::param;
my $might_decode = sub {
my $p = shift;
return ( !$p || ( ref $p && fileno($p) ) )
? $p
: eval { decode_utf8($p) } || $p;
};
*CGI::param = sub {
my $q = $_[0];# assume object calls always
my $p = $_[1];
goto &$param_org if scalar @_ != 2;
return wantarray
? map { $might_decode->($_) } $q->$param_org($p)
: $might_decode->( $q->$param_org($p) );
}
}
}
1;
Re: Apache 2 + perl UTF-8 problem
Torsten Foertsch wrote: On Sun 22 Jun 2008, André Warnier wrote: Now, the first thing I would like to understand is why this is so. Since this is a POST, and since the browser knows that "everything" is UTF-8, I would expect it to send the proper multipart POST, with each item marked as UTF-8. So why does my cgi-bin script not see it as such ? Yes that is the current state. Neither CGI nor libapreq2 does that conversion for you, afaik. You have to do it yourself. Thanks. For the moment, I am dealing with CGI.pm, without mod_perl or libapreq2. I'll deal with those afterward. I see a problem though : as far as I can tell, CGI.pm does not offer any way to find out the "charset" header with which each POST parameter was sent. Or am I missing something ? André
Re: graphics in perl
Malka Cymbalista wrote: We are running perl 5.8.5 on a Linux machine that is running apache 2.2.6 with mod_perl 2.0.3. Our data is in a MySQL database (MySQL 5.0.45) We have been asked to write a web application that requires plotting capabilities. We do most of our web programming in perl so I am looking for a perl module that has the following features: 1. ability to create histograms 2. ability to create x,y plots 3. ability to zoom in on a portion of the graph 4. ability to calculate the distance between 2 points on the graph 5. ability to hover on a point and bring up some text Does anyone have any suggestions for which perl modules we should look into? Thanks for any information. There are a lot of perl APIs built over various graphics packages. You can start with this list: http://search.cpan.org/modlist/Graphics You might also try searching cpan for some specific keywords, because I don't believe all the graphics modules are in that list. For example, I've used Image::Magick for doing some basic image resizing and conversion, but I don't see Image::Magick in that list. -- Jim Albert
Apache (httpd) + Persistant Perl (ModPerl/SpeedyCGI) + User Based Processes (SuExec) + Chroot
I was referred to this mailing list from the following thread on perlmonks (http://www.perlmonks.org/index.pl?node_id=693487) === For years I have been using modperl and have been quite fond of it, the idea of persistant perl interpereter is excellent.The problem however lies with using modperl securely for multiple sites. Ideally, the desired solution is to have each site run in a chroot jail for security, have each site execute under it's own user/group and have a modperl instance for each site.Up until now the best solution I have been able to come up with is as follows:Implementation 1: Top Level Apache Server, Port 80, ModProxy This serves requests via ModProxy to the respective apache servers with mod_perl.Site 1 Apache Server, Port 8081, ModPerl This server runs an instance of ModPerl and all scripts required for Site 1.Apache User: site1Site 2 Apache Server, Port 8082, ModPerl This server runs an instance of ModPerl and all scripts required for Site 2.Apache User: site2This allowed me to have seperate modperl instances, this is done for three reasons: 1) ModPerl does not support user based processes2) This prevents pollution between instances & secures one mod_perl instance from another.3) Each instance can be chrooted for additional security.The problem with this configuration is: 1) Requires a new http server for each additional site/modperl application2) Apache creates a set of workers for each instance (ususally about 7). With 7 required for the Top level proxy, and 7 for each site, this soon adds up. e.g. 5 sites = 7 + (5 * 7) = 49 child workers-Implementation 2:A new solution I have been working on is to have a single Apache server with chrooting suexec and speedycgi.The setup is as follows: 1. Create a Chroot Jail for Apache (Extra Security Measure). 2. Modify suExec to allow chrooting before suid and process execution.3. Install Apache into Chroot Jail4. For each site: a. Create a Jail for each site that includes perl + speedycgib. Create a virtualhost which specifies SuExecUserGroup and the ENV variable used for the chroot.How it works: Apache first resides in a jail, it then serves non-perl requests to static objects as per normal. When a request for a perl script is made: Apache chroots into the site's jail using suexec. Suexec changes to the correct site's user.SpeedyCGI then either: Loads a script into speedy-backend orExecutes a script cached in speedy-backendAdvantages: 1) Provides persistant perl WITH suexec for per-virtualhost user execution2) SpeedyCGI handles dynamic data, Apache handles static, hence you don't require a covering proxy as described in http://perl.apache.org/docs/1.0/guide/strategy.html3) The timeout property in speedycgi means that a script with low or no load will drop out of memory, this means high use scripts will run in persistant perl and low use scripts will load into memory then remove themself when they are no longer being activly used. Disadvantages: 1) Speedycgi seems to be no longer in development, whereas modperl is still in active development.2) I have read somewhere that speedycgi is not as fast as modperl (will have to benchmark the two later).3) Since speedycgi with timeout enabled fades out with inactivity, the first request to an inactive script requires all the modules to be reloaded, whereas modperl exists in memory indefinitly and can load a script on server start, rather than first request. -I was wondering if I could get some feedback on both these designs. I have been researching and testing the second solution over the last few days and would like to get some input.a) Is there a better way to achive this goal?b) Is there a way to make modperl scale and attain the desired results without creating a new server for each instance (Implementation 1)?c) Have I missed anything (security etc. (Implementation 2))?d) Is there a better solution (fastcgi/pperl etc.)?e) What are there any downsides (other than those listed above) to either of these implementations?Finally, are there any suggestions/ideas?James Austin _ Never miss another e-mail with Hotmail on your mobile. http://www.livelife.ninemsn.com.au/article.aspx?id=343869
Re: Apache (httpd) + Persistant Perl (ModPerl/SpeedyCGI) + User Based Processes (SuExec) + Chroot
On Mon, Jun 23, 2008 at 8:46 PM, James Austin <[EMAIL PROTECTED]> wrote: > 1) Requires a new http server for each additional site/modperl application > 2) Apache creates a set of workers for each instance (ususally about 7). > With 7 required for the Top level proxy, and 7 for each site, this soon adds > up. That's entirely under your control. You can start as few or as many as you like, and vary the settings by site if you choose to. You would want about 20 times as many front-end server processes as backend ones to start with. > A new solution I have been working on is to have a single Apache server with > chrooting suexec and speedycgi. SpeedyCGI's only advantage over FastCGI was that it could be installed and used by a non-privileged user on a shared host without any direct support from the hosting provider. At this point, it's been a dormant project for ages. I think you'd better try FastCGI instead. However, I don't really see any advantage to FastCGI over the mod_perl setup you suggested. - Perrin
