Re: [cgiapp] CGI::Application::Plugin::Authentication
I think Cees may thiught about this at the least. I am also copying it to the mailing list. On 31/10/11 20:04, Cliff Green wrote: Hello, I've been struggling to understand how to build a token-based Store for this plugin and not getting much forward movement. Do you know if anyone has put together such a module? It would be very helpful to have a working example to compare with. I've been trying to put together a Store module for CAS (the Yale Central Authentication Service maintained at Jasig). To date I've tried combining the AuthCAS module for the underlying CAS guts (Olivier Salaun's package). c -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Syntax error in CGI::Application::Dispatch
At line 5 there is use Try:Tiny rather than use Try::Tiny. On 08/09/11 17:00, cgiapp-requ...@lists.erlbaum.net wrote: Send cgiapp mailing list submissions to cgiapp@lists.erlbaum.net To subscribe or unsubscribe via the World Wide Web, visit http://www.erlbaum.net/mailman/listinfo/cgiapp or, via email, send a message with subject or body 'help' to cgiapp-requ...@lists.erlbaum.net You can reach the person managing the list at cgiapp-ow...@lists.erlbaum.net When replying, please edit your Subject line so it is more specific than Re: Contents of cgiapp digest... Today's Topics: 1. Re: Multiple exception packages in CAD? (Timothy Appnel) -- Message: 1 Date: Thu, 8 Sep 2011 09:58:32 -0400 From: Timothy Appnel t...@appnel.com Subject: Re: [cgiapp] Multiple exception packages in CAD? To: CGI Application cgiapp@lists.erlbaum.net Message-ID: b3001c3d-abfc-4b7e-b800-5484288bc...@appnel.com Content-Type: text/plain; charset=us-ascii On Jul 28, 2011, at 19:39, Ron Savage r...@savage.net.au wrote: I had a look at the source code for CAD, and it would be trivial to patch to replace Exception::Class::TryCatch with Try::Tiny. If I wasn't so lazy (today) I'd submit a patch myself. You could. I did. The end result was indeed trivial. Class::Exception does precious little in CAD itself from what I can tell. I left it in, but if we wanted to trim dependencies some more that would be a good one to kook at. I pushed it to Mark the other day. You can see it here: https://github.com/tima/CGI--Application--Dispatch/tree/try-tiny Maybe we'll see it in a release by end of year 2013 with my REST tunneling changes. :s tim/ Sent from my iPhone -- ___ cgiapp mailing list cgiapp@lists.erlbaum.net http://www.erlbaum.net/mailman/listinfo/cgiapp End of cgiapp Digest, Vol 48, Issue 1 * -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] CGI::Session
On 07/07/11 01:45, Ron Savage wrote: Hi Nick On Wed, 2011-07-06 at 14:35 +0100, Nicholas Bamber wrote: Ron, You put an explicit version on every dependency. For example Data::Dumper 2.128. That seems unnecessarily modern and Debian curently only has 2.125. If we added the latest version as a package it might need to be removed again later on. I put in the version #s as per what I have installed. I'm using perlbrew V 5.12.2. I'll examine how to wind back these requirements... I had a look at /usr/lib/perl/5.10.1/Data/Dumper.pm and it says V 2.124. I could do that for each pre-req. Usually if a specific version is not required one just puts the version as 0. I appreciate calculating these versions is hard. Also do we really need all this DBIx stuff? The test code uses DBIx::Admin::CreateTable and DBIx::Admin::DSNManager. Data::Session doesn't. Of course that code could be re-written and included within Data::Session without those modules. I'm reluctant to do that, because there's already a Deb package for DBIx::Admin::CreateTable (that's why 'All rights reserved' was removed from the licence section in V 2.06), and I believe DBIx::Admin::DSNManager deserves its own Deb package. Nevertheless, if you think it's worth rewriting that code, feel free to say so. In that case DBIx::Admin::DSNManager should have been in the build requirements not the requirements. All these problems can be worked round as the dependencies in Build.PL are effectively advisory - except for eliminating noise. I can even give you some feedback on minimum versions - at least to the extent your tests capture the requirements. Also DBIx::Admin::DSNManager can be bundled with the package at least until a separate interest in those develops. -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] CGI::Session
The latest release of CGI::Session appears to be unauthorized. I can find it at http://search.cpan.org/~markstos/CGI-Session-4.45/ but ifyou click on permalink it disappears. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] cgiapp Digest, Vol 45, Issue 11
Mark, Thanks for keeping on top of CGI::Application. I am puzzled that Build.PL for CGI::Application::Dispatch mentions CGI::PSGI version 1, which seems not to exist. Both this version and the previous worked fine anyway, so this is more about avoiding an ugly warning than anything else. -- Message: 3 Date: Fri, 24 Jun 2011 10:37:04 -0400 From: Mark Stosberg Subject: Re: [cgiapp] CGI::Application:Dispatch 3.0 test failures To: cgiapp@lists.erlbaum.net Message-ID: iu27ek$6gg$1...@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1 On 06/21/2011 09:16 AM, Mark Stosberg wrote: The new CGI::Application::Dispatch 3.0 release is failing some PSGI-related tests on most-but-not-all platforms: http://www.cpantesters.org/distro/C/CGI-Application-Dispatch.html#CGI-Application-Dispatch-3.00 3.01 was released last night, which hopefully resolves the test failures, which were do a dependency declaration issue. Thanks to Brad Oaks to helping track that down. Mark -- ___ cgiapp mailing list cgiapp@lists.erlbaum.net http://www.erlbaum.net/mailman/listinfo/cgiapp End of cgiapp Digest, Vol 45, Issue 11 ** -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Data::session
Ron, It would *probably* take about twenty minutes of my time, to package it for Debian though with the release freeze it could be weeks before it actually gets into Debian. However there is a presentation on Debian packaging for Perl here: http://pkg-perl.alioth.debian.org/docs/pkg-perl-for-users/pkg-perl-for-users.pdf . cgiapp-requ...@lists.erlbaum.net wrote: Send cgiapp mailing list submissions to cgiapp@lists.erlbaum.net To subscribe or unsubscribe via the World Wide Web, visit http://www.erlbaum.net/mailman/listinfo/cgiapp or, via email, send a message with subject or body 'help' to cgiapp-requ...@lists.erlbaum.net You can reach the person managing the list at cgiapp-ow...@lists.erlbaum.net When replying, please edit your Subject line so it is more specific than Re: Contents of cgiapp digest... Today's Topics: 1. Re: Data::Session/CGI::Session (Ron Savage) -- Message: 1 Date: Fri, 24 Dec 2010 16:37:46 +1100 From: Ron Savage r...@savage.net.au Subject: Re: [cgiapp] Data::Session/CGI::Session To: CGI Application cgiapp@lists.erlbaum.net Message-ID: 1293169066.3514.29.ca...@localhost.localdomain Content-Type: text/plain Hi Nicholas On Sat, 2010-12-18 at 23:37 +, Nicholas Bamber wrote: I notice that a 4.43 o CGI::Session has been released. That should get into Debian in due course. Reviewing the Debian bug list I noticed this: Session file not being written for driver:File; serializer:Storable (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315669) That appears to be related to #482355 Storable.pm segfaults when called during global destruction And from my brief reading of the bug reports this seems to be related to design/backwards compatibility issues in both CGI::Session and Storable. Can I conclude from that, that the best thing to do with #315669 would be to mark it wontfix and to suggest that people bother by the bug try Data::Session (which would of course will need to be packaged)? Yes. This bug report for Storable http://rt.cpan.org/Public/Bug/Display.html?id=36087 indicates that the maintainers of Storable /may/ attempt to rectify the problem with Storable. As I see it, since the problem has been identified as being with Storable, it should not be up to other modules to add special code to compensate for this. I do realise various modules have had special code put in them to compensate for problems with other modules. My policy is that the module with the bug should be fixed, and that workarounds should not be used except, perhaps, in exceptional circumstances. This case is not exceptional, since users can simply switch away from Storable to something reliable. We could add a patch to CGI::Session, but I am not going to patch Data::Session in this manner. What I will do is patch the docs for Data::Session to warn users about the issue with Storable. I suggest the docs for CGI::Session should be likewise updated. Lastly, since I'm a Debian user myself, I could package Data::Session (i.e. in Debian format), given some help, since I only have limited experience with that. If there is someone available, they can email me directly. Thanx for following this up. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Data::Session/CGI::Session
I notice that a 4.43 o CGI::Session has been released. That should get
into Debian in due course. Reviewing the Debian bug list I noticed this:
Session file not being written for driver:File; serializer:Storable
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315669)
That appears to be related to #482355
Storable.pm segfaults when called during global destruction
And from my brief reading of the bug reports this seems to be related to
design/backwards compatibility issues
in both CGI::Session and Storable. Can I conclude from that, that the
best thing to do with #315669
would be to mark it wontfix and to suggest that people bother by the
bug try Data::Session (which would of course will need to be packaged)?
cgiapp-requ...@lists.erlbaum.net wrote:
Today's Topics:
1. Re: Announce: Data::Session - A re-write of CGI::Session
(Ron Savage)
2. Re: Announce: Data::Session - A re-write of CGI::Session
(Larig Tech)
3. Re: Announce: Data::Session - A re-write of CGI::Session
(Ron Savage)
4. Re: Announce: Data::Session - A re-write of CGI::Session (Lyle)
5. Re: Announce: Data::Session - A re-write of CGI::Session
(Ron Savage)
6. Re: Announce: Data::Session - A re-write of CGI::Session
(Mark Stosberg)
7. Re: Mark Stosberg's CPAN project management (Mark Stosberg)
--
Message: 1
Date: Mon, 06 Dec 2010 06:33:24 +1100
From: Ron Savage r...@savage.net.au
Subject: Re: [cgiapp] Announce: Data::Session - A re-write of
CGI::Session
To: CGI Application cgiapp@lists.erlbaum.net
Message-ID: 1291577604.17421.83.ca...@localhost.localdomain
Content-Type: text/plain
Hi
On Sun, 2010-12-05 at 15:53 +, Larig Tech wrote:
Hi Ron,
Given the cost to the coder of switching to a different sessions
implementation,
and the cost to the community of having a separate sessions package, is
there
any discourse on the benefits of adopting Data::Session? At the moment
you've
left me only seeing costs.
I'm not ordering anyone to switch. Everyone can freely choose to stay with
CGI::Session or move.
After some digging I found See
Data::Session::CGISessionhttp://search.cpan.org/~rsavage/Data-Session-1.01/lib/Data/Session/CGISession.pmfor
an extended
discussion of the design changes between
Data::Sessionhttp://search.cpan.org/~rsavage/Data-Session-1.01/lib/Data/Session.pmand
CGI::Session http://search.cpan.org/perldoc?CGI%3A%3ASession.
But again, that just reinforces the costs and none of the benefits; there
must
be some or you wouldn't have gone to all that effort. If it's a redesign
then I'd
expect some examples illustrating what I can do with your package that I
can't do with the two market leaders.
Data::Session is not designed to provide bells and whistles unavailable
with CGI::Session. It's designed with 2 things in mind:
o To provide an almost identical interface, to minimise transition costs
o To be supported
Have you missed the recent traffic on this subject? At the risk of
repeating myself, I'll include here the body of an off-list reply I
typed up minutes ago:
###
It's been born of several years frustration
o I write almost all the patches for CGI::Session
o And have done for several years (since 2006)
o The original author Sherzod Ruzmetov has dropped out of the Perl scene
o The current maintainer is Mark Stosberg
o He refuses to let me be co-maintainer of the module
o Meaning I can't release patches
o The last release by him is V 4.42 in August 2009 (sic)
o Since then I've made many patches [1] (up to V 4.45), but these are
locked up in the repository:
http://github.com/cromedome/cgi-session/tree/master
o Off-list msgs to me have revealed deep disquiet and frustration over
Mark's handling of a number of projects, including CGI::Session
o I have plenty of time available to re-do the code
o Both modules are Open Source...
[1] Here are those patches:
4.45 - Thursday, February 4, 2010
* FIX: Make tests use 't/', or a temp dir, for temp files, not '.'.
* NEW: RT#51191. Update store() in CGI::Session::Driver::DBI,
CGI::Session::Driver::db_file,
CGI::Session::Driver::file, CGI::Session::Driver::mysql and
CGI::Session::Driver::postgresql
to accept a 4th parameter, $etime.
Patch CGI::Session to pass this parameter to the storage mechanism
called within flush().
Note: The code shipped in this module does not yet make any use of this
parameter.
Thanx to Pavel V. Rochnyack.
* NEW: Call query-can('cookie') before trying to call query-cookie().
This means the query object does not have to have a cookie() method.
Add corresponding test t/cookie.free.t.
* NEW: Add {query_class = 'Some::Class'} to the \%session_params in the
calls to new() and load().
This determines
Re: [cgiapp] : CGI::Session
Ron/Jason, Actually, anything and everything which give people information (on which to base decisions pertaining to their own lives) helps. Thanks for the information. This exactly describes my problem. Mark refuses to release until I make changes he insists on. The ostensible reason (as I understand it) is to do with auto-flushing or not when the object is destroyed. My policy is that no user should be /forced/ to execute an explicit flush just before the object goes out of scope. The current code of sub DESTROY() doing a flush is fine as a default. In some cases, e.g. under Plack, the object (really the app) doesn't go out of scope when the app exits, and the user must use flush. But I don't accept that that is a reason to force all non-Plack uses to call flush. It simply doesn't make any sense. I would have thought the correct thing to do is to maintain backwards compatibility but provide support for whatever behaviours might be required. A simple switch to choose between the two behaviours. Maybe there could be a chance to choose the default between the two behaviours at installation time. I also wonder if Mark feels that autoflushing at the end is unreliable and supporting it causes more trouble than it saves both for the maintainer and users. That could be quite a defensible position. The current situation punishes everyone using the current CPAN version, which is the officially-released version, since we know many people work in orgs which will not condone installing from a remote svn or git etc repository. Actually there is nothing to stop you from uploading a distribution to CPAN with a different name, but the same .pm files and forking that way. However I agree that that would be an aggressive action and something of a bridge burning. Mark won't give me co-main power. I suppose I could request it directly from CPAN admins. They might agree. I doubt that they would agree. He still cares about the module and I imagine that is what counts. I'm suggesting the real matter should be dealt with in a (private) manner which does not sabotage release of past, present and future patches. Yes could we also keep the discussion at a technical level and keep pyschobabble out of it. Noone wants their psychiatry to be conducted on a public mailing list and it probably won't be conducive to a good outcome. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] CGI::Session
Ron, There's no point - Mark Stosberg refuses to release any more versions of CGI::Session. http://github.com/cromedome/cgi-session/blob/master/Changes This looks like an abortive attempt to restart development. Are you saying that Mark is trying to prevent further development, or is to busy for an official release or what? # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Data validation of file uploads
There are two Data::FormValidator related modules that handle file uploads. They both take the approach of saying, Well the CGI module param method (or equivalent) gives us a file handle. So whatever we do with the file handle or the underlying file, there must still be a file handle at the end. I cannot see the sense of this approach. It seems much cleaner to me take a two phase approach: 1. Convert the upload file handle (and meta data) into straight data 2. Validate that data. That's the approach I am taking at the moment. Any thoughts? # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Unobtrusive Javascript form validation
The company I work for has also been moving to JQuery, so I won't be surprised if Data.FormValidator gets updated at some point to integrate better with JQuery, possibly on a fork. This is a frustrating thing about javascript. I use YUI. I have very poor experience from trying to mix frameworks. I think this must be a common experience and it must be difficult to share resources across frameworks. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Problems with uploads
Hi Nicholas / A lot of my troubles seem to have come from following the HTML, XHTML, / / and CSS Bible by Steven Shafer which recomends a form like this: / / / / form action=formhandler.cgi method=post enctype=form/multipart // // input type=file id=file size=10/ .. // / / I was slightly puzzled by the use of an id attribute rather than a / / name attribute, when I want to read from this control rather than / / manipulate it in javascript. I fixed that without spotting any other issues. / There is nothing wrong with the id. I always use name and id, myself, and make them the same value. JS code will often require the id, so you should always include it. I thought this pretty much sums it up. http://www.velocityreviews.com/forums/showpost.php?p=699631postcount=2 So I only include when I have CSS or js stuff to hang on it. / It took me a long time to realize that the browser was sending / / CONTENT_LENGTH = 13. I could have spotted this with / / CGI::Application::Plugin::DevPopup::HTTPHeaders which I was using, but I / / did not make the connection until I was actually reading the CGI source. / / When I removed the size attribute this problem went away. / / / / The second problem was that the enctype should be multipart/form-data / / not form/multipart. Fixing that got a CGI::Application file upload / / working. / That's a nasty bug to publish. And size 10 seems very narrow-minded. You should be justifiably suspicious of any other code in the book. Whilst not wanting to rollback on the on the inaccuracy of the text, I should say it was a paraphrase. The text did not specify an actual size, but my understanding is that this size relates to display length of the control, and so should not influence what CONTENT_LENGTH parameter is send to the browser. Most people don't have problems. It's always difficult to know exactly what set-up the user was using. But the bug reports /already/ tell us what needs work. If you can figure out a patch, I'm sure the author of CGI would be delighted to receive it. Oh dear. Where shall I start? Shall I start a Rumsfeldian rant? Or shall I just direct you to lists of quotes about programming (http://www.quotegarden.com/programming.html). Or shall I say Okay. Let's get this right. You are saying that the list in bugzilla can be relied upon to be a complete list of all bugs in CGI.pm. And all we need to do is fix those 63 and then we will have web nirvana. Actually I find the statement If you can figure out a patch, I'm sure the author of CGI would be delighted to receive it. most terrifying, because presumably as far as the authors of CGI know, I could be some crazed maniac (if this email does not confirm such suspicions) and I do hope the contributions get thoroughly reviewed. Then I could go on to point out that CGI.pm is sitting in the middle of what used to be a standards war zone and still is a ignorant, innocent good guys versus clever, devious bad guy hackers war zone. Does anyone still use in Server push - at least in the old sense? It is riddled with legacy (or war wounded?) code, maintains both an OO and a functional interface, compiles stuff on the fly, can be used in hundreds of different ways and so on. Actually whilst I looked through the bug list I noticed at least one person saying it used to work in version X but does not work now. The overall coverage figure seems to be 76%. So that leaves 24% of the code base that could be broken from one release to the next. I would have thought as such contributions that improve test coverage would be a lot more welcome than patches to bugs. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Problems with uploads
I have just had a terrible time getting file uploads to work with CGI::Application. I ended up working with a hacked version of CGI.pm that was writing statements to a local file. I have had to temporarily abandon test-driven development in favour of just get the damn thing working - sort of - development. I have put up a proposal for a better world on perlmonks (http://perlmonks.org/?node_id=846191) but that will have to come in due course. A lot of my troubles seem to have come from following the HTML, XHTML, and CSS Bible by Steven Shafer which recomends a form like this: form action=formhandler.cgi method=post enctype=form/multipart input type=file id=file size=10/ .. I was slightly puzzled by the use of an id attribute rather than a name attribute, when I want to read from this control rather than manipulate it in javascript. I fixed that without spotting any other issues. It took me a long time to realize that the browser was sending CONTENT_LENGTH = 13. I could have spotted this with CGI::Application::Plugin::DevPopup::HTTPHeaders which I was using, but I did not make the connection until I was actually reading the CGI source. When I removed the size attribute this problem went away. The second problem was that the enctype should be multipart/form-data not form/multipart. Fixing that got a CGI::Application file upload working. I still need to go on and do stuff with the file and then implement the security checks. I was hoping to use Data::FormValidator::Constraints::Upload but that does not seem very likely just now. In the middle of all that I had a look at the CGI.pm bug list. Several appear related to upoads Bug #32135 for CGI.pm: Needs Test: some uploads starts to fail with CGI.pm 3.29 Bug #56780 for CGI.pm: Windows 7 and CGI.PM undefined upload handle Bug #55166 for CGI.pm: Bug #53966 for CGI.pm: CGI open of tmpfile: No such file Bug #31107 for CGI.pm: Needs Confirmation: 400 Bad and so on. This scared me enough that I looked at CGI::Simple and CGI::Minimal. The former had quite a few upload bugs and I could not get the latter to work anyway. (I went back to CGI and got that working as described above.) I then ran Devel::Cover on the CGI.pm code downloaded from github: -- -- -- -- -- -- -- File stmt bran cond sub pod time total -- -- -- -- -- -- -- blib/lib/CGI.pm 87.8 75.8 71.9 87.5 37.0 88.3 79.8 blib/lib/CGI/Apache.pm 100.0 n/a n/a 100.0 n/a 0.0 100.0 blib/lib/CGI/Carp.pm 73.0 60.3 47.8 73.9 0.0 0.8 63.3 blib/lib/CGI/Cookie.pm 94.0 65.2 50.0 100.0 43.8 1.3 79.2 blib/lib/CGI/Fast.pm 82.8 66.7 0.0 100.0 0.0 0.1 75.5 blib/lib/CGI/Pretty.pm 74.3 57.7 66.7 58.3 0.0 1.2 65.9 blib/lib/CGI/Push.pm 90.7 62.5 41.7 83.3 0.0 1.8 73.1 blib/lib/CGI/Switch.pm 100.0 n/a n/a 100.0 n/a 0.0 100.0 blib/lib/CGI/Util.pm 73.8 65.2 46.2 73.3 0.0 6.6 64.0 Total 85.0 71.3 66.2 84.3 24.0 100.0 76.0 -- -- -- -- -- -- -- Maybe if we could get the test coverage up, the number of bugs would become more manageable. Nicholas # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] authentication stuff
Jerry,
I hate to say this, but I cannot help thinking you would benefit from
stepping back from the problem.
Start off with a basic CGIApp, add authentication, the add the DBH
plugin, then switch to the DBI based driver then go back to your code.
Even if that does not reveal the problem the exercise would probably be
useful.
Message: 2
Date: Wed, 23 Jun 2010 17:59:31 -0700 (PDT)
From: Jerry Kaidor je...@tr2.com
Subject: Re: [cgiapp] cgiapp Digest, Vol 33, Issue 16
To: CGI Application cgiapp@lists.erlbaum.net
Message-ID:
af0ccbc5100882ecae91c0a101d86f45.squir...@www.jm-properties.com
Content-Type: text/plain;charset=iso-8859-1
Jerry,
Just focusing on this for a moment:
Error executing class callback in prerun stage: must call dbh_config()
before calling dbh().
What this seems to mean is that $options{DBH} is undefined.
I assume you have had CGI::Application working with the standard DBH
authentication driver.
*** You know, I don't remember if I tried that at all. Right now, I'm not
aiming at getting the whole thing working, just to get it past this
particular error. Basically, changes that my driver makes to the options
array ( which it must do, for the system to work without changing your
driver ) seem to be magically discarded when my driver calls your driver.
The crux of the matter would be - does a Perl method get a private copy
of $self-whatever? If so, can this behavior be changed or defeated?
There is another feature that my homegrown session support has: session
timeout is dependant on the network of the user. On the localnet,
timeouts are very long - on the order of weeks. Out on the big wild
Internet,however, they are like a bank's - 15 minutes.
If I get tired of fighting with it, I'll take you up on your kind offer.
But for now, I am learning useful things about perl data structures.
- Jerry Kaidor
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] cgiapp Digest, Vol 33, Issue 16
Jerry,
Just focusing on this for a moment:
Error executing class callback in prerun stage: must call dbh_config()
before calling dbh().
What this seems to mean is that $options{DBH} is undefined.
I assume you have had CGI::Application working with the standard DBH
authentication driver. I am sure you have given previous conversations. If you
have actually got DBH set up correctly then may be you could send me your code
tarred up.
Message: 2
Date: Wed, 23 Jun 2010 08:31:59 -0700 (PDT)
From: Jerry Kaidor je...@tr2.com
Subject: [cgiapp] CAP::Authentication Multi-Driver
To: CGI Application cgiapp@lists.erlbaum.net
Message-ID:
61b4098ad54fc6d09e64363df827b6a4.squir...@www.jm-properties.com
Content-Type: text/plain;charset=iso-8859-1
Hello,
Continuing to try to get my multiple DBI's driver working. As you may
remember, I needed my application to know which database my user
authenticated against.
With Nicholas Bamber's advice, I was off to a good start. I created a
driver ( MULTI_DBI.pm ) which subclasses the DBI driver using use base.
My driver iterates through a hash of labels and dhb's, sending each dbh
to the DBI driver.
Right now, after calling __SUPER__::verify_credentials with
$super_output = $self-SUPER::verify_credentials( $self, @creds );
I get the following error:
Error executing class callback in prerun stage: must call dbh_config()
before calling dbh().
What this seems to mean is that $options{DBH} is undefined.
Using Data::Dumper -
before calling the superclass:
dumper says $VAR1 = 'DBH';
$VAR2 = bless( {}, 'DBI::db' );
$VAR3 = 'DBHS';
$VAR4 = {'ST' = $VAR2,'IP' = bless({},'DBI::db' ),'GLOBAL'
= bless( {}, 'DBI::db' ),'QR' = bless( {}, 'DBI::db' )};
$VAR5 = 'TABLE';
$VAR6 = 'users';
...The important part is $VAR1 and $VAR2, which together are a hash element
defining DBH as some meaningful number ( that I got from the DBI library
when opening the database ). My MULTI_DBI driver added the DBH hash
member
so that the DBI driver would recognize it and verify against that database.
HOWEVER, after calling the superclass I get:
dumper says $VAR1 = 'DBHS';
$VAR2 = { 'ST' = bless( {}, 'DBI::db' ), 'IP' = bless( {},
'DBI::db' ),'GLOBAL' = bless( {}, 'DBI::db' ),'QR' =
bless( {}, 'DBI::db' )};
$VAR3 = 'TABLE';
$VAR4 = 'users';
...Note that there are only 4 VARs. And there is no DBH hash. Apparently,
Perl has kindly removed any changes that I made to the options hash/array.
One thought I had was that $self had somehow changed. But no:
(top of MULTI_DBI::verify_credentials )
CGI::Application::Plugin::Authentication::Driver::MULTI_DBI=HASH(0x89be0a8)
(top of DBI::verify_credentials
CGI::Application::Plugin::Authentication::Driver::MULTI_DBI=HASH(0x89be0a8)
looks like the same number to me
Anybody know the magic to get new stuff to stick in $self-options?
(Mostly fighting my own ignorance here, I know )
Thanks in advance,
- Jerry
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
[cgiapp] Using HTTP chunked transfer with CGI::App?
Hi Des, I would suggest that you look into AJAX and try to handle rather more on the client/javascript side. If you will permit I will give some hints on how I would approach it. There are alternatives but I primarily use the YUI framework for javascript stuff. 1.) The CGI::Application part should largely just initiate the process. 2.) You need a second back-end process (not strictly part of the web application) to do the actual work. 3.) Your CGI::Application should support a run mode that returns a progress report. This would not be a web page in the normal sense. The MIME type should probably be application/json rather than text/html and you should wrap it with the JSON perl module. 4.) The YUI connection manager provides a good AJAX framework. http://developer.yahoo.com/yui/connection/. Using the connection manager the client side gets the JSON data described in 4. and parses it using http://developer.yahoo.com/yui/json/ . 5.) You do the actual display using http://developer.yahoo.com/yui/progressbar/ . If that is all too javascript heavy for you then you should be able to at least do 1. and 2. Then your web page should display the status and put in some automatic refresh in the headers until the work is complete. The one thing you really cannot do is leave the browser wating whilst the work completes. Nicholas Message: 1 Date: Fri, 18 Jun 2010 14:40:06 +0100 From: Des Herriott des.herri...@gmail.com Subject: [cgiapp] Using HTTP chunked transfer with CGI::App? To: cgiapp@lists.erlbaum.net Message-ID: aanlktimlmmkxcuoqeoxxcd25mg7b4wit6nn7skman...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm working on a CGI::Application app which needs to run some potentially slow tasks, and I want to keep the user updated about its progress. The runmodes I'm using: - show_request_form - display the initial request form - show_preview - once the user has entered their data, display a list of the work that will be done - submit_request - carry out the actual work The submit_request runmode will run several tasks, some of which could be quite slow. The overall run time of this runmode could be 20-30 seconds, so I want to keep the user updated after each task is completed. It seems like HTTP chunked transfer is what I need here, but I'm having trouble understanding how to make it work with CGI::App. Since CGI::App runmodes basically constructs the entire page and return it, I can't see a way to return one chunk of the page at a time. Am I missing something, is there perhaps a useful a plugin to progressively render some output, or is this just not going to work? Thanks, # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Multiple Authentications?
Jerry, The answer to your title question is yes - you can have multiple DBI drivers. There is an example in the main documentation where there are two Generic drivers and that should carry across. However I don't think this will quite do what you want. First of all the authentication module does not handle authorization (i.e. permissions). So according to CAP::Authentication every user is either authenticated or not and every page is either protected or unprotected. Authorization should govern access to specific objects which is a much more vague problem. There is a CAP::Authorization module but I have never looked at it. Secondly the code does not remember which driver finally authenticated the user. Message: 1 Date: Tue, 8 Jun 2010 11:50:40 -0700 (PDT) From: Jerry Kaidor je...@tr2.com Subject: [cgiapp] Multiple Authentications? To: CGI Application cgiapp@lists.erlbaum.net Message-ID: 3544e006eabdd6392534177e71aff063.squir...@www.jm-properties.com Content-Type: text/plain;charset=iso-8859-1 Hello, I see that CAPAuthentication will let you install multiple drivers. Can one install multiple instances of the same driver, only with different parameters? Here's my situation: My business has three locations - let's call them locA,locB,locC. The database for each location has a users table which contains usernames, MD5 passwords, and a constellation of permissions for each user. There is also a global users table. Its structure is exactly the same as the users tables for the individual locations. The permissions in this table apply to ALL the locations. So if user Bob appears in the global table and has permission foo, then inq_can_foo( Bob ) returns TRUE for all the locations. If, OTOH, Bob appears in LocA, then inq_can_foo(Bob) will only return TRUE if we happen to be in locA's web page. I'm thinking that I could register four DBI drivers, one for each database. Then the system would just try each users table until it got a match. I don't think it would scale well, though. But it would get things going for now, and with all of the authentication stuff buried in one or two files, I could easily change it in the future. After authentication - for the duration of the session - I would have to remember which database the user authenticated against, because that effects the permissions. - Jerry Kaidor p.s. I have gotten my entire project under Subversion, generated a branch for this work, and had a great time yesterday removing all the print statements from my HTML-generating code. Svn's method of doing branches - just create a separate directory for each one - seems rather hokey - but as long as it can reliably do merges, I guess I don't care. -- ___ cgiapp mailing list cgiapp@lists.erlbaum.net http://www.erlbaum.net/mailman/listinfo/cgiapp End of cgiapp Digest, Vol 33, Issue 8 * # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Incompatibility between CAP::Authentication and CAP::ActionDispatch
I've uploaded 0.17_5 which has the ActionDispatch fix and hopefully should run fine without ActionDispatch being installed. The question Christian raises about Dispatch is interesting. As Christian points out I am not a fan of setting up run modes by setting subroutine attributes. I can see that it makes the code look nice but I do not see what the practical benefits are. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Security, Authentication and Authorization for CGI::App
Brad, If you have any feedback on CGI::Application::Plugin::Authentication I would appreciate it. My priorities for it are (not in any order): 1.) Getting it to run under taint mode 2.) And making the HTML more configurable 3.) Getting test coverage up. 4.) Keeping test failures down 5.) Working through the bugs in rt. I am also thinking about the big picture on authentication but I have been working on the module for too shorter time to have any definite ideas. Today's Topics: 1. Security, Authentication and Authorization for CGI::App (Brad Van Sickle) -- Message: 1 Date: Thu, 04 Mar 2010 10:56:17 -0500 From: Brad Van Sicklebvansick...@gmail.com Subject: [cgiapp] Security, Authentication and Authorization for CGI::App To: CGI Applicationcgiapp@lists.erlbaum.net Message-ID:4b8fd821.5050...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed I'd like to get the list's opinion on some security practices for CGI::Application. In a lot of my applications I'm noticing that I need to secure things at many different levels and this is resulting in me having a security infrastructure that is very spread out and hard to manage/change. Specifically, I need to be aware of the following things when implementing security: 1) Authentication - figuring out who the user is and if they have access to app at all 2) Runmode Authorization - figuring out of the user has access to perform the specific function they are requesting 3) Data authorization. - In quite a few apps I'm noticing the need to allow multiple users or user types to have access to the same runmode, but I need to show them a specific set of information based on who they are. Example, I may have a end user role tied to an organization and a management user role, who has permission to see and manage data for a group of those organizations so I need to adjust the data output accordingly. The way I handle that today is: 1) Authentication is pretty simple, I have a Security application that provides the login form, processes the login, hands out the session and then redirects the user to the actual app. 2) Runmode authorization is a little trickier, but still manageable. I check the user's session in prerun and if they are not authenticated, redirect to a not authorized runmode that redirects them back to the security app (login page) Any module that needs to set security on specific runmodes, inherits prerun and does if checks against the runmode/usertype to make sure they are authorized. Anyone trying to go somewhere they shouldn't is redirected to that same not authorized runmode. 3) Data authorization is the part I'm least happy with. I often find myself pulling keys (groupID, organizationID, etc..) out of the user profile, doing an if check on user type, and then dynamically setting WHERE clauses on my DB queries according to what user type I'm dealing with and what information they are allowed to see. It's cumbersome and hard to manage. My problems with my current approach: 1) This seems to work ok. 2) My authorization scheme works, but doing things like adding new user roles, changing permissions, etc... can get messy and I feel there is probably a better way. I'd love to be able to ask my security application who this person is and if they are allowed where they want to go. I think there are modules that do this to at least some extent, but I still have to keep that list somewhere and not sure just moving it's location makes things easier. 3) As I mentioned, my data authorization scheme is very hard to manage and I'd love to find a better way. I just don't have any ideas about what that better way is. Obviously it's easier to do some query alteration to display different data than to write entirely new applications or modules to cater to different user types/access levels, but when requirements change, new user types are added, etc... it can be a considerable amount of work to alter all the if checks on the queries accordingly. This is also notoriously difficult to test for, because of the sheer volume of test cases. I apologize for the extreme length of this, but I wanted to give a good overview of what I'm doing today and see if any of the smarter, more experienced members of the list might be able to give me any suggestions about how to make my security more modular/portable and easier to manage. Thanks -- ___ cgiapp mailing list cgiapp@lists.erlbaum.net http://www.erlbaum.net/mailman/listinfo/cgiapp End of cgiapp Digest, Vol 30, Issue 7 * # CGI::Application community mailing list #### ## To unsubscribe, or change your message
