Re: [Catalyst] Authorization header absent under mod_fcgi
Hi, Andy Grundman schrieb: I'm going to look into this. I hope there's a sane way to get it to work without having to special-case the Authorization header. See my posting Engine::(Fast)CGI and Basic Auth in Apache 2 on 29.02.2008. In short: Catalyst::Engine::CGI does only copy environment settings =~ /^(?:HTTP|CONTENT|COOKIE)/i; whereas in Apache2 the env setting is called 'Authorization' and the FastCGI engine subclasses Catalyst::Engine::CGI. So basically one has to fix repare_headers() in Catalyst::Engine::CGI or subclass the FastCGI as a workaround. Bye -Thomas smime.p7s Description: S/MIME Cryptographic Signature ___ 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] implementing ajax
jennifer wrote: Thanks for your suggestions. I was a little reluctant to explor JSON because I didn't find the cpan documentation or catalyst book being sufficient. Being that this application is my first with catalyst, I wanted to tackle one thing at time. Catalyst first, then all the plug in modules. If you could provide a working example of hos to implement the js and catalyst controller part of JSON, I would greatly appreciate it! A couple of articles here http://catalyst.perl.org/calendar/2007/9 http://catalyst.perl.org/calendar/2007/1 Regards, Peter ___ 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] Instant CRUD with DBIC::Schema
On 12 Mar 2008, at 21:50, Zbigniew Lukasiak wrote:
After some more playing with CatalystX::CRUD I think I can formulate
my arguments a bit more clearly.
OK, bear in mind that you're competing with Reaction here. Reaction
has some promise, but its development is slow so far (for casual
users anyway), and it may suffer from some of the hyperverbosity and/
or (superficially) excessive indirection that is endemic in
enterprise ready™ software. I'm not qualified to comment further on
this.
I believe the objects that users of CatalystX::CRUD get in their
controller should be the real things - i.e. objects from their models
not CatalystX::CRUD::Model::Objects. This would be the minimal
interface and minimal hassle for injecting CatalystX::CRUD::Controller
actions to a legacy Catalyst controller.
What I particularly like about InstantCRUD is that everything is
spelled out nicely for the coder once they run the helper. That is,
mostly once you've been through the catalyst learning curve, the
instantcrud learning curve isn't very much more at all.
InstantCRUD's main problem is HTML::Widget, and secondarily the lack
of many-to-many introspection. I'm not sure how big the problem with
the tight coupling with DBIC is - I'd like to see a shitfight between
merlyn and mst, with zby as mediator to straighten that one out. Or
maybe between merlyn and zby with mst mediating ...
I think it would be best to be able to treat a CatalystX::CRUD
application like any other catalyst application. That is, minimal
modification of $c-model('Foo') compared to an ordinary catalyst app
so that the CRUD generator mostly gets out of the way.
For bonus points I'd like to see a REST service available by default,
with a browser based service available on top of this. This way we
get the API for free and the browser UI gets to forward to the REST
API (with suitable massaging of the stash).
___
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] Instant CRUD with DBIC::Schema
On Wed, Mar 12, 2008 at 12:33 PM, Kieren Diment [EMAIL PROTECTED] wrote:
On 12 Mar 2008, at 21:50, Zbigniew Lukasiak wrote:
After some more playing with CatalystX::CRUD I think I can formulate
my arguments a bit more clearly.
OK, bear in mind that you're competing with Reaction here. Reaction
has some promise, but its development is slow so far (for casual
users anyway), and it may suffer from some of the hyperverbosity and/
or (superficially) excessive indirection that is endemic in
enterprise ready™ software. I'm not qualified to comment further on
this.
Yeah - I hope there is a room for two competitors here.
I believe the objects that users of CatalystX::CRUD get in their
controller should be the real things - i.e. objects from their models
not CatalystX::CRUD::Model::Objects. This would be the minimal
interface and minimal hassle for injecting CatalystX::CRUD::Controller
actions to a legacy Catalyst controller.
What I particularly like about InstantCRUD is that everything is
spelled out nicely for the coder once they run the helper. That is,
mostly once you've been through the catalyst learning curve, the
instantcrud learning curve isn't very much more at all.
InstantCRUD's main problem is HTML::Widget, and secondarily the lack
of many-to-many introspection. I'm not sure how big the problem with
the tight coupling with DBIC is - I'd like to see a shitfight between
merlyn and mst, with zby as mediator to straighten that one out. Or
maybe between merlyn and zby with mst mediating ...
I think it would be best to be able to treat a CatalystX::CRUD
application like any other catalyst application. That is, minimal
modification of $c-model('Foo') compared to an ordinary catalyst app
so that the CRUD generator mostly gets out of the way.
Just thinking how this can be done - you need a
CatalystX::CRUD::ModelAdaptor:: and a model_adaptor_class config
option for the CRUD controller. Then in the controller methods you
would do:
$c-stash-{object} = $self-model_adaptor-fetch( @arg );
instead of
$c-stash-{object} = $c-model( $self-model_name )-fetch(@arg);
and in places where you call methods on the object like: $obj-$method
you could do again $self-model_adaptor-$method( $obj ).
This way $c-stash-{object} could still be an unmodified object from
the model and you would have your indirection layer needed to make the
CRUD methods universal.
Cheers
Zbigniew
For bonus points I'd like to see a REST service available by default,
with a browser based service available on top of this. This way we
get the API for free and the browser UI gets to forward to the REST
API (with suitable massaging of the stash).
___
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/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
___
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::Plugin::Server::XMLRPC and default action
If I make an XMLRPC request to an invalid XMLRPC endpoint $c-action is not set. (For a normal 404 request I end up with a default action). I have plugins and other code that calls methods on $c-action so those don't work so well when $c-action is undefined. This a bug in the plugin or do I need to somehow define a default XMLRPC action? -- Bill Moseley [EMAIL PROTECTED] ___ 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] implementing ajax
I'm going to have to be the red-headed stepchild that advocates XML... -Original Message- From: Mesdaq, Ali [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2008 5:19 PM To: The elegant MVC web framework Subject: RE: [Catalyst] implementing ajax Jennifer, Are you sure you want to stick with this route? Looks like your going to make a lot of work for yourself. I would hate to see the js code to make xml. Use the js code to just post the values you want read those values I can't speak too much on the generation of XML on the client, but I do advocate the use of POST rather than uploading an XML body. Most of the popular JS toolkits make this quite easy. Why would you want to use JSON? Because javascript can just read it straight in and you can use it without having to parse anything. Your js would just eval the returned json content and use it. If you return xml you will need to parse it out and just makes a lot of work. The main reason against JSON for me is security. Something that can be eval'd is very dangerous and I'm sure we're all aware of the cross-site vulnerabilities that take advantage of JSON returned data. The one thing that's always mentioned as total failsafe against it is to *not* use JSON as your returned data structure. As far as parsing the XML, that's why I use ExtJS. I can define a Store and use XPath to map Record fields to my XML data - ExtJS does the rest. It's a bit like having a Model of my data on the client side. Just my 2 cents. v/r -matt pitts ___ 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] Instant CRUD with DBIC::Schema
On 03/12/2008 05:50 AM, Zbigniew Lukasiak wrote: After some more playing with CatalystX::CRUD I think I can formulate my arguments a bit more clearly. I believe the objects that users of CatalystX::CRUD get in their controller should be the real things - i.e. objects from their models not CatalystX::CRUD::Model::Objects. This would be the minimal interface and minimal hassle for injecting CatalystX::CRUD::Controller actions to a legacy Catalyst controller. Let me outline the problem I was trying to solve, and maybe you can suggest an alternate solution. Or explain why the problem I see is not the problem you see. My original idea for CX::CRUD was to design an API that was high-level enough that a CRUD Controller would not need to know anything specific about a CRUD Model, except what was defined by the CX::CRUD API. That is, if I was using Rose::HTML::Objects to manage my forms, my Controller could exchange DBIC for RDBO as its Model and not need to change any Controller code. Likewise, the Model need not know anything about the Controller except what was defined by the API. Ideally, all the logic for Controller and Model is encapsulated within each, and they talk to each other minimally and only through well-defined methods. Some levels of indirection were thus required. CX::CRUD is duct tape, but it ought to be sensible and predictable how the duct tape works. So then the questions began. Assuming I have a $form and an $object: (1) where and how should they interact? Should they interact in the Controller or the Model? Or somewhere not either of those? (2) should the $form and $object have any expectations about the methods available on the other object? Or how else can they interact in a relatively agnostic way? From a programming philosophy perspective, I could be persuaded about the answer to (1). I don't have strong opinions. IME, it's more practical for me in my Cat apps to put workflow kinds of code in a Controller, make my Models as thin as possible, and put as much code as possible in classes outside of Catalyst altogether. For CX::CRUD, I compromised, based on the pattern I followed in Catalyst::Controller::CRUD, and put the basic $form/$object interaction in the Controller, and made the Model a thin/convenient wrapper around the non-Catalyst model class(es). I did this because, to my way of thinking, it makes a sensible parallel construction to implement Form processing in the Controller and storage processing (business logic, whatever you want to call it) in the Model. The Model knows nothing about Forms; the Form is just one way of getting data to and from the Model, and since facilitating workflow is what a Controller does, the Form belongs in the Controller. Since I decided to put the $form/$object code in the Controller, the answer to (2) became more obvious to me: the objects should have some common expectations about each other. In the case of the $object, the $form should expect the $object to implement the basic CRUD methods: create() read() update() delete(). That's where CatalystX::CRUD::Object came from. It abstracts those 4 methods and leaves it up to CX::CRUD::Model authors to implement them for their particular model package (ORM, whatever). In the case of the $form, the $object should expect some way of getting and setting data (moving data to/from) the $form. That's where the CX::CRUD::Controller config values for 'init_form' and 'init_object' come from, and why the form_to_object() method is not implemented in the base Controller but left up to the specific Form implementation (like in CX::CRUD::Controller::RHTMLO). Now granted, a lot of my API ideas are influenced by how RHTMLO and RDBO work. I don't apologize for that; I like those APIs, which is why I use those packages. But I can understand that the DBIC/FormFu folks think differently, which is why there is more than one ORM and Form package out there. :) So, assuming I have identified the design problems correctly, I can imagine an alternate solution. Get rid of CatalystX::CRUD::Object. Put the create/read/update/delete methods in CatalystX::CRUD::Model instead. Change the base Controller behaviour to do this: $c-model( $self-model_name )-create( $object ); instead of this (what it does currently): $object-create; Now, I like the current implementation because it is (a) terser and (b) seems clearer to me what is happening. But if the design goal of common expectations for $form and $object is to be achieved, we need some way of defining that API. I'm open to suggestions of how to get rid of CX::CRUD::Object and still defining a way for Controllers to be Model agnostic. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive:
Re: [Catalyst] Instant CRUD with DBIC::Schema
On 03/12/2008 06:33 AM, Kieren Diment wrote:
On 12 Mar 2008, at 21:50, Zbigniew Lukasiak wrote:
After some more playing with CatalystX::CRUD I think I can formulate
my arguments a bit more clearly.
OK, bear in mind that you're competing with Reaction here. Reaction has
some promise, but its development is slow so far (for casual users
anyway), and it may suffer from some of the hyperverbosity and/or
(superficially) excessive indirection that is endemic in enterprise
ready™ software. I'm not qualified to comment further on this.
I didn't get the sense that CX::CRUD is competing with Reaction. CX::CRUD is,
as mst put
it, a simple solution for a simple problem. Reaction seems to have loftier
goals.
By simple I mean it is supposed to be simple for the user. Subclass
CX::CRUD::Controller::RHTMLO and you've adapted your existing RHTMLO form to
Catalyst. The
idea is the same as for jrockway's Model adapter.
Authors of CX::CRUD Models and Controllers (like zby is attempting with DBIC
and FormFu)
may find it not so simple. Then it's up to us to hash out whether that is the
fault of the
documentation or the API or the design. Or some combination of those.
I believe the objects that users of CatalystX::CRUD get in their
controller should be the real things - i.e. objects from their models
not CatalystX::CRUD::Model::Objects. This would be the minimal
interface and minimal hassle for injecting CatalystX::CRUD::Controller
actions to a legacy Catalyst controller.
What I particularly like about InstantCRUD is that everything is spelled
out nicely for the coder once they run the helper. That is, mostly once
you've been through the catalyst learning curve, the instantcrud
learning curve isn't very much more at all. InstantCRUD's main problem
is HTML::Widget, and secondarily the lack of many-to-many
introspection. I'm not sure how big the problem with the tight coupling
with DBIC is - I'd like to see a shitfight between merlyn and mst, with
zby as mediator to straighten that one out. Or maybe between merlyn and
zby with mst mediating ...
I think it would be best to be able to treat a CatalystX::CRUD
application like any other catalyst application. That is, minimal
modification of $c-model('Foo') compared to an ordinary catalyst app so
that the CRUD generator mostly gets out of the way.
Clarification: CX::CRUD is *not* a code generator. It is not like InstantCRUD
in that
sense. Or really in any sense. CX::CRUD is first an API and second a collection
of base
classes to make implementing that API easier for specific packages. That is, I
never use
CX::CRUD in my Catalyst apps. I use CX::CRUD::Controller::RHTMLO and
CX::CRUD::Model::RDBO
quite a lot. So does Rose::DBx::Garden::Catalyst, with which you might be
confusing CX::CRUD.
For bonus points I'd like to see a REST service available by default,
with a browser based service available on top of this. This way we get
the API for free and the browser UI gets to forward to the REST API
(with suitable massaging of the stash).
CX::CRUD::REST is part of the core dist. It is designed to make swapping
between REST and
RPC-style APIs as trivial as:
use base qw( CatalystX::CRUD::REST CatalystX::CRUD::Controller::SomeThing );
where SomeThing is currently RHTMLO or (hopefully soon) FormFu.
--
Peter Karman . [EMAIL PROTECTED] . http://peknet.com/
___
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] Authorization header absent under mod_fcgi
Andy Grundman schrieb:
Yeah, it's a bug in mod_fastcgi but we can work around it easily.
Lighttpd properly passes the header as HTTP_AUTHORIZATION. For
mod_fastcgi we'll have to do this:
if ( $env{Authorization} ) {
$env{HTTP_AUTHORIZATION} = delete $env{Authorization};
}
I have a patch and a test and will check it in soon.
Great. Thanks!
smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Instant CRUD with DBIC::Schema
On 03/12/2008 10:27 AM, Zbigniew Lukasiak wrote: If you'd make them to use the same db connection than indeed this would be like the ModelAdaptor. But then again you should have just on adaptor per model type - not per table (for models with tables). certainly if you think CX::CRUD::Model::DBIC should be implemented that way, I encourage you to do so. The RDBO approach is 1class=1table, so the RDBO Cat Model follows that. All the classes can share (or not) a single DBI connection; that's up to how the underlying RDBO classes are configured. The db connection information is not part of CX::CRUD::Model::RDBO. It is only the DBIC model that requires that information. RDBO uses a separate class (Rose::DB) to implement DBI handle management, and that information is in the (non-Catalyst) RDBO classes. CX::CRUD::Model is completely agnostic about storage, connections, etc. It's up to the implementation to handle that part. If you like the model_adaptor() syntax in the Controller API, how would you implement a ModelAdaptor class and how would you change the Controller API to use it? You've left this part of my email unanswered... :) -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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] Instant CRUD with DBIC::Schema
On Wed, Mar 12, 2008 at 4:27 PM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
On Wed, Mar 12, 2008 at 4:12 PM, Peter Karman [EMAIL PROTECTED] wrote:
On 03/12/2008 09:44 AM, Zbigniew Lukasiak wrote:
So we'd have:
sub thing : Local {
my ($self, $c, $id) = @_;
my $thing = $c-model('Foo')-fetch( id = $id );
my $thing = $self-model_adaptor-fetch( id = $id );
The model adaptor should know the model it is using (and in the case
of DBIC also the table )
In my example, $self is not a CX::CRUD::Controller. Just a plain ol'
Catalyst::Controller.
Why must it implement a model_adaptor method then?
OK - so that was just a misunderstanding - I thought we were still
talking about the CRUD methods.
$c-stash-{object} = $thing; # NOT a CX::CRUD::Object
}
and if wanted to update $thing:
$c-model('Foo')-update( $thing );
$self-model_adaptor-update( $thing );
I could live with that. Does it meet your needs? Does it make it
easier to implement a
DBIC model and FormFu controller?
Yes. In general - my point is that let's do the wrapping only for the
CRUD methods that need them. Let's not force the user to use the CRUD
wrappers as their models.
Users of CX::CRUD Models or Controllers don't have to use both together.
It's just easier
if they do. And CX::CRUD doesn't force you to only use its models.
You could have:
lib/MyApp/Model/Foo.pm # not a CX::CRUD::Model. Just a DBIC::Schema
model.
lib/MyApp/Model/FooCRUD.pm # is a CX::CRUD::Model::DBIC
MyApp::Model::FooCRUD can act like your ModelAdaptor. By adding yet
another kind of thing,
a model adaptor, into the mix, that feels more complex to me rather than
less.
If you'd make them to use the same db connection than indeed this
would be like the ModelAdaptor. But then again you should have just on
adaptor per model type - not per table (for models with tables).
That should be: just one adaptor class per model type (class).
I think I'm agreeing with you that the CX::CRUD API could be simplified,
that the ::Object
class could go away, and that the Model class could take over the c/r/u/d
methods that
Object currently performs.
Yeah - I would consider the objects on the stash as part of the
interface so they should be the original ORM objects.
If you like the model_adaptor() syntax in the Controller API, how would
you implement a
ModelAdaptor class and how would you change the Controller API to use it?
--
Peter Karman . [EMAIL PROTECTED] . http://peknet.com/
___
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/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
___
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] implementing ajax
* On Wed, Mar 12 2008, Matt Pitts wrote: The main reason against JSON for me is security. Something that can be eval'd is very dangerous and I'm sure we're all aware of the cross-site vulnerabilities that take advantage of JSON returned data. Don't parse JSON with eval. Use a parser. (How do you think Perl parses JSON?) It's a code vs. data issue. Yes, evalling code is dangerous. So don't do that. Treat your data as data and you won't have a problem. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ 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] Instant CRUD with DBIC::Schema
* On Wed, Mar 12 2008, Zbigniew Lukasiak wrote: don't need to create wrappers for each table (which would be a cut and paste excercise). Well, a metaprogramming exercise anyway. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ 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] implementing ajax
-Original Message-
From: Jonathan Rockway [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2008 12:12 PM
To: The elegant MVC web framework
Subject: Re: [Catalyst] implementing ajax
* On Wed, Mar 12 2008, Matt Pitts wrote:
The main reason against JSON for me is security. Something that can
be
eval'd is very dangerous and I'm sure we're all aware of the cross-
site
vulnerabilities that take advantage of JSON returned data.
Don't parse JSON with eval. Use a parser. (How do you think Perl
parses JSON?)
It's a code vs. data issue. Yes, evalling code is dangerous. So
don't
do that. Treat your data as data and you won't have a problem.
Sure, I can do this in my own client-side JS, but what if I can't trust
the client? Even if my returned JSON is purely JSON structure (no var x
= { JSON DATA };, just { JSON DATA }) can I still be guaranteed
that if someone does:
script type=text/javascript
src=http://myapp.com/some/cat/action/that/returns/json/data;/script
in their own pages that the local JS engine won't actually put my data
(with potential user info) into memory and allow a malicious person to
get it? I see where you could maybe make this same argument against XML,
but since JSON is really, really close to being eval-able as JS code
whereas XML is not, I'd rather err on the side of caution.
If data is data and you have to use a parser anyway, then again, why not
use a format that is less vulnerable to malicious access?
v/r
-matt pitts
___
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] implementing ajax
I'm sure that JSON and all the other goodies are perfect tools for
implementing ajax, but i would like to learn what's really going on in
teh black box before I use it.
So far, my javascript is able to send an xmlhttprequest to my catalyst
controller method which then does some processes and outputs data into
an xml document. i'm having trouble sending that document over to my
xmlhttprequest.responseXML object.
in my controller:
my $writer = new XML::LibXML::Document;
... do some process and spit out into an xml document...
$c-response-content_type('text/xml');
$c-response-write($writer);
When the xmlhttprequest is ready, I plan to parse the req.responseXML
object using XMLSerializer in my javascript code.
Thanks for everybody's input. I look forward to the day I can explore
JSON and others!
Jennifer
Matt Pitts wrote:
-Original Message-
From: Jonathan Rockway [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2008 12:12 PM
To: The elegant MVC web framework
Subject: Re: [Catalyst] implementing ajax
* On Wed, Mar 12 2008, Matt Pitts wrote:
The main reason against JSON for me is security. Something that can
be
eval'd is very dangerous and I'm sure we're all aware of the cross-
site
vulnerabilities that take advantage of JSON returned data.
Don't parse JSON with eval. Use a parser. (How do you think Perl
parses JSON?)
It's a code vs. data issue. Yes, evalling code is dangerous. So
don't
do that. Treat your data as data and you won't have a problem.
Sure, I can do this in my own client-side JS, but what if I can't trust
the client? Even if my returned JSON is purely JSON structure (no var x
= { JSON DATA };, just { JSON DATA }) can I still be guaranteed
that if someone does:
script type=text/javascript
src=http://myapp.com/some/cat/action/that/returns/json/data;/script
in their own pages that the local JS engine won't actually put my data
(with potential user info) into memory and allow a malicious person to
get it? I see where you could maybe make this same argument against XML,
but since JSON is really, really close to being eval-able as JS code
whereas XML is not, I'd rather err on the side of caution.
If data is data and you have to use a parser anyway, then again, why not
use a format that is less vulnerable to malicious access?
v/r
-matt pitts
___
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] implementing ajax
On Wed, Mar 12, 2008 at 4:53 PM, Matt Pitts [EMAIL PROTECTED] wrote:
-Original Message-
From: Jonathan Rockway [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2008 12:12 PM
To: The elegant MVC web framework
Subject: Re: [Catalyst] implementing ajax
* On Wed, Mar 12 2008, Matt Pitts wrote:
The main reason against JSON for me is security. Something that can
be
eval'd is very dangerous and I'm sure we're all aware of the cross-
site
vulnerabilities that take advantage of JSON returned data.
Don't parse JSON with eval. Use a parser. (How do you think Perl
parses JSON?)
It's a code vs. data issue. Yes, evalling code is dangerous. So
don't
do that. Treat your data as data and you won't have a problem.
Sure, I can do this in my own client-side JS, but what if I can't trust
the client? Even if my returned JSON is purely JSON structure (no var x
= { JSON DATA };, just { JSON DATA }) can I still be guaranteed
that if someone does:
script type=text/javascript
src=http://myapp.com/some/cat/action/that/returns/json/data;/script
in their own pages that the local JS engine won't actually put my data
(with potential user info) into memory and allow a malicious person to
get it? I see where you could maybe make this same argument against XML,
but since JSON is really, really close to being eval-able as JS code
whereas XML is not, I'd rather err on the side of caution.
Just use server side auth for sensitive data. Using a format that's
slightly harder to parse is no protection at all.
If data is data and you have to use a parser anyway, then again, why not
use a format that is less vulnerable to malicious access?
___
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] implementing ajax
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2008 1:50 PM
To: The elegant MVC web framework
Subject: RE: [Catalyst] implementing ajax
Matt Pitts [EMAIL PROTECTED] wrote on 03/12/2008 11:53:45 AM:
-Original Message-
From: Jonathan Rockway [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2008 12:12 PM
To: The elegant MVC web framework
Subject: Re: [Catalyst] implementing ajax
* On Wed, Mar 12 2008, Matt Pitts wrote:
The main reason against JSON for me is security. Something that
can
be
eval'd is very dangerous and I'm sure we're all aware of the
cross-
site
vulnerabilities that take advantage of JSON returned data.
Don't parse JSON with eval. Use a parser. (How do you think Perl
parses JSON?)
It's a code vs. data issue. Yes, evalling code is dangerous. So
don't
do that. Treat your data as data and you won't have a problem.
Sure, I can do this in my own client-side JS, but what if I can't
trust
the client? Even if my returned JSON is purely JSON structure (no
var x
= { JSON DATA };, just { JSON DATA }) can I still be
guaranteed
that if someone does:
script type=text/javascript
src=http://myapp.com/some/cat/action/that/returns/json/data;/script
in their own pages that the local JS engine won't actually put my
data
(with potential user info) into memory and allow a malicious person
to
get it? I see where you could maybe make this same argument against
XML,
but since JSON is really, really close to being eval-able as JS code
whereas XML is not, I'd rather err on the side of caution.
If data is data and you have to use a parser anyway, then again, why
not
use a format that is less vulnerable to malicious access?
Matt,
I have absolutely no idea what additional security you are
inferencing by this email. If you toss sensitive data out whether the
format is json, xml, or xor 3|\|CoD3d it is still in their hands.
Obviously, one shouldn't put out sensitive info. without some form of
authorization, I made the *assumption* that authorization was *assumed*
for my scenario. However...
That's the point of cross-site scripting attacks, they get to
authenticated pages by using the client's browser to access the page.
The scenario I outlined is much like some of the Gmail cross-site
vulnerabilities...
http://jeremiahgrossman.blogspot.com/2006/01/advanced-web-attack-techniq
ues-using.html
My argument is this: if you want to return sensitive data for an AJAX
app doing so using eval-able JS or even pure JSON increases the risk
that your data could be hijacked via cross-site attacks.
v/r
-matt pitts
___
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] implementing ajax
On Mar 12, 2008, at 11:55 AM, Matt Pitts wrote:
My argument is this: if you want to return sensitive data for an AJAX
app doing so using eval-able JS or even pure JSON increases the risk
that your data could be hijacked via cross-site attacks.
Like everything else it's only risky if you do it wrong. Always wrap
it in {}. Enforce authn/authz; even the suggestion that you might
not is horrific/ludicrous. Know what you're sending. Don't let users
put code on your site in their data. All the usual suspects from there.
-Ashley
___
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] Instant CRUD with DBIC::Schema
On Wed, Mar 12, 2008 at 8:07 PM, Peter Karman [EMAIL PROTECTED] wrote: On 03/12/2008 01:24 PM, Zbigniew Lukasiak wrote: We are closing to it. Basically the adaptor needs to store the table name in it's instance - that's all. So one adaptor per table? How is that different than one model per table? It is one instance of adaptor per table instead of one class of adaptors per table. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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/ -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ ___ 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] Re: Google Summer of Code
* Kieren Diment [EMAIL PROTECTED] [2008-02-26 14:15]: Essentially gluing existing stuff together like OpenID, FOAF, Various levels of access control, REST and the like to produce a distributed social networking system. Just FYI, that sounds like DiSo: http://code.google.com/p/diso/ I don’t think there’s direct synergy here, but it seems to me that having a conversation between the projects would be a good idea. I very much like the idea of using the web itself as the social network instead of using a walled garden built on top of it. Regards, -- Aristotle Pagaltzis // http://plasmasturm.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] not working URLS
Hi, On the page http://dev.catalystframework.org/wiki/Faq_ref#sc.1 In the section Best practices there is a link to: http://home.ngmedia.net/chansen/catalyst/conf/ that doesn't seem to display anything related to Catalyst. If somebody know if I could find the content of that page somewhere, please let me know. That page should contain set of web server configurations that you can build your environment from. (samples for Apache 1.3, 2.0, and lighttpd utilizing mod_perl, speedycgi, fastcgi, and standard cgi) Thanks. Octavian ___ 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/
