Re: [Catalyst] Authorization header and fastcgi

2009-02-19 Thread Mark Trostler

are you looking in  $c-engine-env?
Mark

Ian Docherty wrote:

Matt Pitts wrote:

-Original Message-
From: Ian Docherty [mailto:catal...@iandocherty.com]
Sent: Tuesday, February 17, 2009 9:51 AM
To: The elegant MVC web framework
Subject: [Catalyst] Authorization header and fastcgi

Hi
The 'Authorization' header is not being passed to my Catalyst
application.

I have read the archives about fastcgi not passing the header and I
have
tried the following in my Apache 2 config

RewriteCond %{HTTP:Authorization} ^(.+)
RewriteRule ^(.*)$ $1 [E=HTTP_AUTHORIZATION:%1,PT]

FastCgiIpcDir /var/fcgi_ipc
FastCgiServer
/var/www/www.pharmaventures.com/script/pharmaventures_fastcgi.pl
-pass-header HTTP_AUTHORIZATION -pass-header Authorization -processes


5
 

-initial-env PV_DEBUG=0 -initial-env PV_HBX=1 -initial-env
PV_DSN=dbi:mysql:port=3306:host=127.0.0.1

I don't see a header and I don't see any environment variable in my


Cat
 

app.

I have tried variations on the -pass-header Authorization -pass-header
AUTHORIZATION but neither works.

Any other ideas?



The following is working for me in Apache 2.2 with FastCgiExternalServer
and Cat 5.8014

RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.+)
RewriteRule ^(.*)$ $1 [E=HTTP_AUTHORIZATION:%1,PT]

Without any special declarations on my FastCgiExternalServer directive.

Could it be something specific to running the FastCGI internal vs.
external?

Did you forget to turn RewriteEngine On?

v/r
-matt pitts

__

'RewriteEngine On' was there, it makes no difference.

I too am on Cat 5.7014

I will experiment with changing between FastCGI static and dynamic mode 
to see if that makes any difference.


Regards
Ian


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/




___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Accessing request environment variables under fastcgi?

2008-10-17 Thread Mark Trostler

They're all in a hashref here: $c-engine-env
Mark

Chris Weyl wrote:

Hey all --

So, I might be a bit crazy here, and there might be a perfectly good way 
to do this that I'm not aware of, and my searches aren't returning 
anything useful.  Hitting me with a clue-stick is quite welcome. :-)


I'm working on a site where all of the users already have SSL certs 
identifying themselves installed in their browser (for a different site, 
same project).  I'd like to have Apache handle the messy SSL bits, and 
Apache already provides me with the directives needed to do this, 
including authenticating the cert by checking the its signature against 
the signer's CA.  Apache also provides a whole slew of environment 
variables, on a per-request basis, for exactly this. [1]  I'm then 
planning on examining what of the authentication modules I can 
steal^H^H^H^H^Hliberate to do client authentication based on what apache 
is saying.  I'm using mod_fcgid as that's what is packaged with Fedora.


These variables don't seem to be passed on through to the app.

My questions:

1) Is there a way I can get at these SSL_* environment varialbes, on a 
per-request basis, from my app?

2) It looks to me like the only sane way to do this is to patch
mod_fcgid to pass the SSL_* vars through as headers.  (e.g.
SSL_CLIENT_VERIFY becomes x-ssl_client_verify -- and does the whole
prepend x- seem sane?)  (This works, and I have such a patch.)
3) ...or, maybe, use some mod_rewrite incantation that's eluded me so 
far, though I'm unsure mod_fcgid passes env variables through at all.
4) Is there something I'm missing/overlooking here?  Does 
Catalyst::Engine::FastCGI stash the passed %env somewhere?  Or is there 
some other way I can get at it?


Thanks-
   -Chris

[1] http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#envvars

--
Chris Weyl
Ex astris, scientia




___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Catalyst::*::REST and Javascript

2008-08-12 Thread Mark Trostler
Ya I agree that doc is a little wacky - I tend to craft my own urls  
set the HTTP method appropriately - I stick the JSON-encoded data in a 
'data' request parameter  have my auto sub in my Root controller peel 
it off of there  put it in $c-data so it all looks the same after that.


like:

if (my $data = $c-stash-{raw_params}-{data}) {
$c-req-data(decode_json($data));
}


Mark

Robert Krimen wrote:


On Mon, Aug 11, 2008 at 9:57 PM, Mark Trostler [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


I've had good luck with ExtJS:

http://extjs.com/learn/Manual:RESTful_Web_Services

   Mark

 
Wikipedia demonstrates REST like:


   userResource = new Resource('http://example.com/users/001')
   userResource.delete()

Whereas ExtJS seems to be of form:

   userResource = new Resource('http://example.com/users?id=001')

The difference being that REST-proper encapsulates the id of the user in the
URI path, where as ExtJS includes it as a query parameter.

I like the former technique because it dovetails with Catalyst's 
chaining paradigm nicely.


Looks like best practice for now is to craft URIs manually and feed them 
into your YUI, jQuery, or

ExtJS AJAX routine of choice.

Rob





___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Catalyst::*::REST and Javascript

2008-08-11 Thread Mark Trostler

I've had good luck with ExtJS:

http://extjs.com/learn/Manual:RESTful_Web_Services

Mark

Peter Karman wrote:



J. Shirley wrote on 8/11/08 10:03 PM:


I use YUI extensively in conjunction with REST -- it works great.
Takes a very minimal amount of work to connect
Catalyst::Controller::DBIC::API::REST with the YUI DataTable, too.

YUI 2.5.1 has better methods for setting the content type, too, so you
can serialize out as JSON without doing weird hacks that were
previously needed (in case you saw someone, probably me, bitching
about that last year :))


(YUI 2.5.x)++

There are examples of using YUI with both RPC and REST style services here:

http://search.cpan.org/~karman/Rose-DBx-Garden-Catalyst-0.09_04/

That uses RDBO, RHTMLO, CatalysX::CRUD(::REST) and YUI 2.5.x specifically.



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Running java inside Catalyst

2008-06-22 Thread Mark Trostler

You can use Java.pm  there are no system calls...
Mark

Lindolfo Lorn Rodrigues wrote:

No, i didn't know, i looked at the source and it's true :(
at least Inline::Java it's better than a simple system(java ... ) ?


On Sun, Jun 22, 2008 at 5:58 PM, Jonathan Rockway [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


* On Sun, Jun 22 2008, Lindolfo \Lorn\ Rodrigues wrote:
  system function it's a bad idea, if you really need to run Java
inside Perl, i
  did not try that inside Catalyst,  you can check Inline::Java http://
  search.cpan.org/~patl/Inline-Java-0.52/Java.pod
http://search.cpan.org/%7Epatl/Inline-Java-0.52/Java.pod
  I think that will not a problem to use Inline::* inside Catalyst.

You do know that Inline::Java uses system() to call java, right?

Regards,
Jonathan Rockway

--
print just = another = perl = hacker = if $,=$

___
List: Catalyst@lists.scsys.co.uk mailto:Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/




--
--Lindolfo Lorn Rodrigues
www.slackwarezine.com.br http://www.slackwarezine.com.br
http://lornlab.org
http://sao-paulo.pm.org
use Catalyst;




___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

2008-05-16 Thread Mark Trostler
I'm sorry but something just feels wrong about your approach - feels 
like your mixing at matching REST  a UI on top.  Get the REST part down 
first,  then worry about something the browser can see on top of it.  I 
don't think you should let 'what a browser can see' to influence the 
REST design.
Get the primitives, GET to search, POST to insert, PUT to update, and 
DELETE to remove working.
Then you, or someone else, can layer something nice for the browser on 
top of that.  Letting what the 'browser can see (or do)' influence your 
RESTful design is just a bad idea I think if you're trying to create a 
REST controller.
Now if you wanted to create just a generic CRUD controller that sort of 
looked like REST or borrowed some ideas from it, then fine.
I guess the problem myself ( others perhaps) are having is calling what 
 I think you're proposing 'REST'.

Mark

Dave Rolsky wrote:

On Fri, 16 May 2008, Zbigniew Lukasiak wrote:

Why would anyone care about GET vs POST? I guarantee most users don't 
care.


If you mean they want to use a form, that has nothing to do with the 
method.

Forms can submit GET requests.


It might need to be a POST if you need to download a file as one of
the search arguments (for example for searching for a similar
picture).


I think you mean _upload_, right?

The URI you propose could be RESTful, if you think of search as a 
noun,

maybe short for search results.


OK - what I was argumenting about is that sometimes it is convenient
to have an URI like that.  The other part of the argument is that if
you have an uri '/cd/search' - then you should not use '/cd/1' to
retrieve the CD object - because then you mix data with commands (id
with actions).


I have no strong opinion on this. I was just pointing out which URIs 
were RESTful and which weren't.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/




___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] Catalyst / dbix-class / mysql / REST job

2008-05-07 Thread Mark Trostler

The job description is kinda crapy:

http://jobs.perl.org/job/8624

But you can work in Sunnyvale, CA or Carslbad, CA.

The backend in Catalyst/REST/DBIx::Class/MySQL.

Frontends are currently command line/library using Moose and lots of 
AJAXy Javascript (using ExtJS - yah should be YUI ideally...).


Join the team!
Mark

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/