Re: New Windows mod_perl2/libapreq2 build available

2021-03-09 Thread Russell Lundberg
I share my kudos for the efforts of Steve Hay and others like him.

and of course to Andre Warnier, a frequent and valuable contributor to this
forum.

I love mod_perl. Speeding up scripts was what first attracted me. But
developing web apps using the Apache API is what keeps me using.

Many thanks, and kind regards,

Russell
--
Russell Lundberg
Denver, Colorado +1 (808) 217-6975
Follow me on LinkedIn <https://th.linkedin.com/in/russelllundberg> | Twitter
<https://twitter.com/intent/follow?screen_name=telecomvoices> | Let's talk
<https://app.acuityscheduling.com/schedule.php?owner=14702481=8878125>
 | Subscribe to CafeTele Newsletter <https://cafetele.ck.page/newsletter>


On Tue, Mar 9, 2021 at 11:08 AM André Warnier (tomcat/perl) 
wrote:

> Many thanks.
> Nowadays, we tend to deal increasingly with Linux servers rather than
> Win32/64, but it is
> nice anyway that someone cares for this, as we still have some customers
> with legacy Win
> servers that they want to keep and update from time to time.
> (And it is also nice for our development/support workstations).
>
> We have quite a few real-world applications based on perl and mod_perl,
> which in
> themselves have been running reliably for years without any needed changes
> due to perl itself.
> But we do get in trouble from time to time because customers insist on
> changing the
> platform on which these applications are running.
>
> By the way, and in the somewhat OT gist of the discussions about perl's
> evolution, I feel
> that there is one argument about perl that is being consistently
> overlooked and/or
> undervalued :
> The fact that applications written in perl many years ago (as much as 20
> years sometimes),
> are still running unchanged today, despite numerous changes of versions,
> platforms, OS'es
> etc.. (*)
> I do not think that there is *any* other current programming language (or
> "framework")
> which equals that record.
>
> This may sound a bit like a "dinosaur" argument, but just think of all
> the  time and
> resources (and thus ultimately, money) which people programming in other
> languages have
> had to spend during the same period, just to keep the same things running,
> and you can get
> a measure of perl's "productivity" in comparison.
>
> I totally understand the desire of some to modernise perl and make it more
> attractive to
> new generations of programmers. But it would be a shame if in the process,
> perl (5,7) lost
> this rather unique quality and positioning.
>
> P.S. And of course, that longevity and stability of perl, is all to the
> credit of people
> like you, who have been supporting and maintaining it over the years, for
> (in my view)
> much too little public recognition and reward in the end.
>
> (*) a bit more on topic : the most "traumatic" events in those many years
> as far as our
> perl programming was concerned, have been the changes from Apache 1.x to
> 2.0, and later
> the changes from 2.2 to 2.4 in terms of AAA. (So, not in perl itself, but
> in the way it
> interacts with Apache).
> I think that nothing else really "registered", even over many OSes such as
> all the
> versions of Windows-es, SunOS, Solaris, HP/UX, AIX, Unix-es, Linux, to
> name only the few
> which I remember running our applications on. Applications of which we
> only ever needed
> one version, running everywhere.
>
> On 05.03.2021 13:12, Steve Hay wrote:
> > For those who are interested, I have uploaded a 64-bit build of
> > mod_perl-2.0.11 and libapreq2-2.15 components compatible with Apache
> > Lounge 2.4.46 (Win64, VC16, built 18 February 2021) and Strawberry
> > Perl 5.32.1.1 (64bit).
> >
> > You can download it from: https://people.apache.org/~stevehay/
> >
> > The SHA1 digest is: 33e231eb91901007e25fd78eb5643901672c519b
> >
> > Regards,
> > Steve
> >
>
>


Re: Apache 2.4, AAA, Shibboleth

2020-03-06 Thread Russell Lundberg
Andy, could your custom auth handler run before Shiboleth, test for a Shiboleth 
token? If not present, use push_handler to run Shiboleth? If the Shiboleth 
token or cookie is present, don’t run Shiboleth?

Russell

Sent from my iPhone

> On Mar 6, 2020, at 08:26, André Warnier (tomcat/perl)  wrote:
> 
> Hi experts.
> 
> In our Apache 2.4(+mod_perl) setups, we use the following kind of thing :
> 
> ...
>PerlAddAuthzProvider UMA-user AUTH::UMA2->authz_user
> ...
>
>  AuthName ALUtop
>  AuthType shibboleth
>  PerlSetVar UMA_AuthType "SAML2"
>  ShibRequestSetting requireSession 1
>  ShibRequestMapperAuthz Off
>  ShibUseHeaders On
>  ShibUseEnvironment Off
>  PerlSetVar UMA_Debug 3
>  
>Require UMA-user valid-user
>Require shibboleth
>  
> ...
> 
> 
> which basically means :
> we combine 2 AAA methods :
> - one is our own (AUTH::UMA2 above, mod_perl based)
> - the other is SAML, via Shibboleth (and all the directives above with "shib" 
> in them, correspond to the Shibboleth installation instructions)
> 
> (The reason being : the corporate user authentication happens via SAML, but 
> it does not provide us enough information about the user. So we run another 
> additional scheme, which supplements the user information, in order to feed 
> more complete data to our applications.)
> 
> Our own AAA method is such, that once the user has been authenticated once, 
> we set a token, such that for subsequent requests we do not need to 
> re-authenticate the user.
> But no matter what we do at that level, the Shibboleth authentication runs 
> anyway.(*)
> 
> And my question is : considering the above setup, would mod_perl provide a 
> way, through some mod_perl API, to disable the Shibboleth authentication (on 
> a request-by-request base), when our own authz module determines that we do 
> not need it to run anymore for the current request ?
> 
> (replace Shibboleth by any other authentication that would be configured in 
> addition to our own; I'm looking for some "generic" mechanism, not only for 
> Shibboleth).
> 
> Or is it so that different authentication methods/modules don't insert 
> themselves in any standard way which can easily be interfaced with in order 
> to dynamically disable them ?
> 
> Note: Shibboleth itself does caching of its prior authentication, and it is 
> not really a big performance hit to re-run it each time, and we can live with 
> it as it is. But in the absolute, it is unnecessary for 90% of the accesses 
> to the applications, so it just sounds like disabling it would be a 
> nice/efficient thing to do.
> 
> I thought of dynamically removing the "Require shibboleth" e.g., but there 
> does not seem to be an API to do that.
> 
> 


Re: POST large amount of data causes segmentation fault

2020-02-09 Thread Russell Lundberg
You might want to have a look at Apache2::SizeLimit instead
https://perl.apache.org/docs/2.0/api/Apache2/SizeLimit.html

You might decide to limit the count if numbers which get submitted with a
single form.
--
Russell Lundberg
Latest Blog Post for Telecom Pros:  Are you stuck with a messy mobile
network?
<https://www.linkedin.com/pulse/you-stuck-messy-mobile-network-russell-lundberg/>
Denver, Colorado +1 (808) 217-6975
Follow me on LinkedIn <https://th.linkedin.com/in/russelllundberg> | Twitter
<https://twitter.com/intent/follow?screen_name=telecomvoices> | Let's talk
<https://app.acuityscheduling.com/schedule.php?owner=14702481=8878125>
 | Subscribe to CafeTele Newsletter <https://cafetele.ck.page/newsletter>


On Sun, Feb 9, 2020 at 5:57 PM Scott Alexander 
wrote:

> Hi,
>
> I meant I'm posting data from a form, javascript is collecting a series of
> numbers from a  as a string.
> Javascript seperates each number with a '/' then I use split within Perl
> to get the list of numbers into an array.
>
> The length of the URL where the data is being posted to is just
> send_message01.pl
> The length of URL is fine.
>
> It's the length of the string being posted which causes problems. If I
> reduce it's length then it works.
>
> I have a  with list of users and GSM numbers. If that list is about
> 600 users it has worked fine. I was testing with about 4000 users when I
> came across this problem.
>
>
>
>
>
>
> Terveisin/Regards
>
> *Scott Alexander*
> Asiantuntija, järjestelmät  Systems Specialist
>
> Humak
> Humanistinen ammattikorkeakoulu
> University of Applied Sciences
> www.humak.fi
>
> Tel. +358 (0)50 411 9556
>
> scott.alexan...@humak.fi
>
> --
> *From:* Russell Lundberg 
> *Sent:* 09 February 2020 12:12
> *To:* Scott Alexander 
> *Cc:* modperl@perl.apache.org 
> *Subject:* Re: POST large amount of data causes segmentation fault
>
> Scott,
>
> Are you saying that the incoming request has a length of 42,000+
> characters?
>
> Apache docs say 8,192 characters is the maximum length of a URL.
>
> Would it be possible to reduce the length of the request until the
> segmentation fault stops occurring?
> --
> Russell Lundberg
> Latest Blog Post for Telecom Pros:  Are you stuck with a messy mobile
> network?
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fpulse%2Fyou-stuck-messy-mobile-network-russell-lundberg%2F=02%7C01%7C%7C2ca2abfe915a4ad6894708d7ad48a4fd%7Ca30a558eb6084b2c8f39a7fa426fa49d%7C0%7C0%7C637168399832316870=g2VxSCwTl1pz1jweDR6TT0qN9BUHEXxb7n06dcTV634%3D=0>
> Denver, Colorado +1 (808) 217-6975
> Follow me on LinkedIn
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fth.linkedin.com%2Fin%2Frusselllundberg=02%7C01%7C%7C2ca2abfe915a4ad6894708d7ad48a4fd%7Ca30a558eb6084b2c8f39a7fa426fa49d%7C0%7C0%7C637168399832316870=ce7xE6Pf5ZPZKpmvx%2FmyxlFTT2wDW6sKxXzAzTvuLnk%3D=0>
>  | Twitter
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fintent%2Ffollow%3Fscreen_name%3Dtelecomvoices=02%7C01%7C%7C2ca2abfe915a4ad6894708d7ad48a4fd%7Ca30a558eb6084b2c8f39a7fa426fa49d%7C0%7C0%7C637168399832326861=19UcZ%2Fy3nYBZXlQIemhpMe3Hxny1Oocvob02BSctkek%3D=0>
>  | Let's talk
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapp.acuityscheduling.com%2Fschedule.php%3Fowner%3D14702481%26appointmentType%3D8878125=02%7C01%7C%7C2ca2abfe915a4ad6894708d7ad48a4fd%7Ca30a558eb6084b2c8f39a7fa426fa49d%7C0%7C0%7C637168399832336856=X%2FX2ndBiqmihpNjNB%2FuomBiBur6OjqDrDSEzkNDheGA%3D=0>
>  | Subscribe to CafeTele Newsletter
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcafetele.ck.page%2Fnewsletter=02%7C01%7C%7C2ca2abfe915a4ad6894708d7ad48a4fd%7Ca30a558eb6084b2c8f39a7fa426fa49d%7C0%7C0%7C637168399832336856=ka4gOUc%2FRvbgeBm%2FV63A5irCo7tkiy4DbcskuCZ8R6o%3D=0>
>
>
> On Sun, Feb 9, 2020 at 4:49 PM Scott Alexander 
> wrote:
>
> Hi,
>
> I have in my code
>
> $req = Apache2::Request->new($r);
>
> My code gets to line 41 then causes a "child pid 13766 exit signal
> Segmentation fault (11)"
>
> $r->log_error("LINE 41") ;
> @number = split /\//, $req->param("numbers") ;
> $r->log_error("LINE 43") ;
>
> the incoming numbers contains a string of mobile numbers which in this
> test is 3900 numbers long and each number is 10-12 characters long.
> javascript tells me the length of the posted string is 42260 characters
> long.
>
> Any idea how to fix this problem?
>
> httpd -v
> Server version: Apache/2.2.15 (Unix)
> Server built:   Jun 19 2018 15:45:13
>
> but I get the same error on the production server which is
>
> Server version: Apache/2.4.6 (CentOS)
> Server built:   Aug  8 2019 11:41:18
>
>
> Terveisin/Regards
>
> *Scott Alexander*
> Asiantuntija, järjestelmät  Systems Specialist
>
> Humak
> Humanistinen ammattikorkeakoulu
> University of Applied Sciences
> www.humak.fi
>
> Tel. +358 (0)50 411 9556
>
> scott.alexan...@humak.fi
>
>


Re: POST large amount of data causes segmentation fault

2020-02-09 Thread Russell Lundberg
Scott,

Are you saying that the incoming request has a length of 42,000+ characters?

Apache docs say 8,192 characters is the maximum length of a URL.

Would it be possible to reduce the length of the request until the
segmentation fault stops occurring?
--
Russell Lundberg
Latest Blog Post for Telecom Pros:  Are you stuck with a messy mobile
network?
<https://www.linkedin.com/pulse/you-stuck-messy-mobile-network-russell-lundberg/>
Denver, Colorado +1 (808) 217-6975
Follow me on LinkedIn <https://th.linkedin.com/in/russelllundberg> | Twitter
<https://twitter.com/intent/follow?screen_name=telecomvoices> | Let's talk
<https://app.acuityscheduling.com/schedule.php?owner=14702481=8878125>
 | Subscribe to CafeTele Newsletter <https://cafetele.ck.page/newsletter>


On Sun, Feb 9, 2020 at 4:49 PM Scott Alexander 
wrote:

> Hi,
>
> I have in my code
>
> $req = Apache2::Request->new($r);
>
> My code gets to line 41 then causes a "child pid 13766 exit signal
> Segmentation fault (11)"
>
> $r->log_error("LINE 41") ;
> @number = split /\//, $req->param("numbers") ;
> $r->log_error("LINE 43") ;
>
> the incoming numbers contains a string of mobile numbers which in this
> test is 3900 numbers long and each number is 10-12 characters long.
> javascript tells me the length of the posted string is 42260 characters
> long.
>
> Any idea how to fix this problem?
>
> httpd -v
> Server version: Apache/2.2.15 (Unix)
> Server built:   Jun 19 2018 15:45:13
>
> but I get the same error on the production server which is
>
> Server version: Apache/2.4.6 (CentOS)
> Server built:   Aug  8 2019 11:41:18
>
>
> Terveisin/Regards
>
> *Scott Alexander*
> Asiantuntija, järjestelmät  Systems Specialist
>
> Humak
> Humanistinen ammattikorkeakoulu
> University of Applied Sciences
> www.humak.fi
>
> Tel. +358 (0)50 411 9556
>
> scott.alexan...@humak.fi
>


Re: HTTP and MPM support

2019-01-28 Thread Russell Lundberg
As a long-time fan and user of mod_perl, I like so much the way this
conversation is turning.

I also wonder if there is a formal process, perhaps an ASF process, for
coordinating the objectives voiced in this thread with the resources
required to achieve them?

For example, I believe Steve Hay has led mod_perl2 development lately,
versions 2.0.9 and 2.0.10, anyway.  Should he be engaged, or if the
leadership of the project has been handed off, whoever has taken over?  Do
the project steward(s) follow this mailing list?

I don't mean to get in the way of positive and well-intended progress. I
love mod_perl and only want the best for its future development.

But there might be other development plans in progress with which
coordination would be helpful.

--
Read my Latest Blog Post for Telecom Pros:  *Excel Telecom Tricks -
Sequential Numbering
<https://bangkokbeachtelecom.com/sequential-numbering/>*
Russell Lundberg
Bangkok, Thailand +66 91 546 4539
https://bangkokbeachtelecom.com/
LinkedIn Profile <https://th.linkedin.com/in/russelllundberg>


On Mon, Jan 28, 2019 at 8:04 AM John Dunlap  wrote:

> I will second what Sive is saying. My organization does not have in-house
> experience writing C code(our internal skill sets are web application and
> database development) but we are potentially interested in sponsoring some
> development on mod_perl with the goal of adding support for mpm_worker and
> or mpm_event because we are interested in taking advantage of mod_http2. In
> addition to our sponsorship, we could also assist in testing changes and
> provided segfaults and debugging/environmental information from out
> development and testing environments. Is anyone who is able to do this kind
> of development interested in having a conversation with Sive and myself
> with respect to sponsoring some development?
>
> On Mon, Jan 28, 2019 at 1:11 AM Sive Lindmark  wrote:
>
>> Hi William!
>>
>> Count on us, my firm can sponsor work as I stated before, and also
>> contribute setting up test cases and perhaps also do some coding if we have
>> the knowledge to do whats needed.
>> My coders are not used to be part of any open source project, so we can
>> not take any leading roll though.
>>
>> How could a sponsor model work?
>>
>> I have followed crypto world for some time now, and they sometimes set up
>> price for someone thats achieve a goal. Something we can do here?
>>
>> /Sive
>>
>>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *j...@lariat.co *
>
> *Customer Service:*
> 877.268.6667
> supp...@lariat.co
>


Re: Upgrade to Debian stretch (stable) breaks my unique token

2018-03-01 Thread Russell Lundberg
“Demos fall over” is a universal truth. 

Glad a fix was found!

Sent from my iPhone

> On Mar 1, 2018, at 17:00, Michael A. Capone  
> wrote:
> 
>> On 03/01/2018 02:30 PM, Vincent Veyron wrote:
>> 
>> Now, if you happen to know why this _had_ to surface during a demo [:-(
> 
> The University of Nottingham, School of Mathematical Sciences, published a 
> highly technical paper explaining this phenomenon.  Hope this helps:  :-)
> 
> https://www.maths.nottingham.ac.uk/personal/ibf/some.html


Re: CGI module deprecation

2017-11-26 Thread Russell Lundberg
I suggest Template::Toolkit (
http://search.cpan.org/~abw/Template-Toolkit-2.27/)  Most of my web apps
are also relatively light on HTML, for which T::T works great. And to your
well-founded concern, T::T makes it pretty easy to keep separate logic and
presentation.

Although keep in mind that is a process, not an event.  T::T also allows
you to embed logic in the templates, so let the programmer beware.

T::T also works terrific with mod_perl, which is useful if your apps are
database-intensive.  mod_perl also has other capabilities to allow you to
move away from the CGI module.  libapreq/Apache::Request

--
Read my Latest Blog Post:  Historical Forecasts for Your BTS Project Tracker
<https://bangkokbeachtelecom.com/add-historical-forecasts-to-your-project-tracker/>
Russell Lundberg - sent from my iPhone
Bangkok, Thailand +66 91 546 4539
https://bangkokbeachtelecom.com/
LinkedIn Profile <https://th.linkedin.com/in/russelllundberg>

On Mon, Nov 27, 2017 at 11:25 AM, Igor Chudov <ichu...@gmail.com> wrote:

> I am a very long term user of the famous CGI module. My biggest project is
> www.algebra.com. There are al;so many others.
>
> Let me mention that my use of perl on the web, a very long time ago,
> started out with Embperl.
>
> At that time, I thought that use of HTML templates with perl code
> sprinkled in is a great idea. It was not.
>
> About two years later, I realized that use of "perl inside HTML" is
> completely unsuitable for the complex things that I was doing, and I
> abandoned Embperl and switched to the CGI module. The CGI module uses "HTML
> generation from perl" and that was much more suitable for me for two
> reasons. One reason is that my web apps are heavy with logic and relatively
> light with HTML. The other reason is that I like to separate presentation
> from application logic, and using perl in proper manner made that easy to
> accomplish.
>
> Fast forward to today, I can see that CGI module is being deprecated!
>
> The alternatives to it, suggested by CGI::Alternatives, seem to force on
> me a different paradigm of development. For example, HTML template seems to
> be a rerun of Embperl. That gives me bad heartburn.
>
> Several other frameworks are completely different functionally, in ways
> that seem to be not very compatible with my thinking.
>
> Anyway, I am sort of open minded to not use perl CGI module for HTML
> generation. Now what?
>
> Is there a HTML generation perl module that does not force me to use
> "different paradigms", but that simply makes outputting HTML from perl an
> easy and maintainable task?
>
> Thanks a lot. I am not looking to start a flamewar. I hope that I did not
> insult anyone. If I did, I apologize. All I want it to find a way to
> generate HTML without switching to completely new, or discarded like
> Embperl, paradigmatic choices. Thanks a lot.
>