Re: [Catalyst] Usage of $c-uri_for and $c-res-redirect
$c-uri_for pulls it's base path from $c-req-base. Quoting the
documentation in the code:
If your application was queried with the URI
Chttp://localhost:3000/some/path then Cbase is Chttp://localhost:3000/
.
So, setting $c-req-base to your new base would do the trick for you I
think.
You would just do $c-req-base('http://www.mysite.tld:443')
I'm sure they're are other ways to do this too.
On Wed, Mar 26, 2008 at 4:31 PM, Dustin Suchter [EMAIL PROTECTED] wrote:
Can you directly control the port you redirect to? Part of my
problem is having consistency between the production and test
environments, which operate on 80/443 and 3000/3000 respectively.
-d
Ashley wrote:
There are two approaches which have helped me. Remember the URI object
underneath can be your friend.
1) Keep things relative.
$c-uri_for(/blah)-path
$c-uri_for(/blah)-path_query
2) Change the scheme yourself.
my $uri = $c-uri_for(/blah);
$uri-scheme( $my_test ? http : https );
-Ashley
On Mar 26, 2008, at 1:13 PM, Dustin Suchter wrote:
Let's say I want to send people back and forth between an HTTP
connection and an HTTPS connection on a server based on some action.
For example, clicking on a logout button from within my application
while connected via HTTPS does something like:
$c-res-redirect(http://foo.com/;);
The above seems like a fine solution except it totally disregards the
beauty of uri_for, which I would love to be using for stuff like this.
Without uri_for, problems arise when you do things like test via the
built in Perl webserver (the one running on port 3000 by default)
while on the same webserver as my production application.
So the real question is, how do I properly refer to my webserver
and/or application root and include port or SSL flags? I guess I'm
looking for something like $0 within uri_for.
-d
___
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/
___
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/
--
do() || do_not(); // try()
Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane
mittam
http://www.kylehultman.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] Re: implementing ajax
I think the 2007 Calendar had a great Javascript/JSON/Catalyst tutorial.
http://catalyst.perl.org/calendar/2007/9
If you've never used javascript with callbacks before, or even if you have,
it's a great reference.
Honestly, I find myself modeling much of how I use javascript after how that
example works,
as it's really a simple approach - and simple is better imho.
The only /real/ vulnerability to JSON - as I understand it, and I could be
wrong - is when you read JSON from untrusted hosts. JSON doesn't have the
requirement like XML does that the response come the from the same host that
you requested it from - and this where some of the cross-site scripting
exploits come in to play (as I understand it). But I'm sure there are some
pretty good ways of mitigating that risk. The two ways I can think of off
the top of my head are: including a sha-1 challenge in every request, and
sha-1 response with the returned data; or just crypt every data field with a
cheap encryption scheme using a certificate you push to the client.
Actually, I just read a great article on pushing certs to the client:
http://drnicwilliams.com/2008/02/22/zero-sign-on-with-client-certificates/
Infact, here a couple articles that hit the AJAX(y) JSON/XSS/etc..
vulnerabilities - but really, look at the data your serving and your
potential audience when deciding on the level of security you need:
http://secwatch.org/advisories/1020538/
http://www.securityfocus.com/infocus/1881
http://jibbering.com/blog/?p=514
http://jpsykes.com/47/practical-csrf-and-json-security
On Thu, Mar 13, 2008 at 5:57 AM, Aristotle Pagaltzis [EMAIL PROTECTED]
wrote:
* Jennifer Ahn [EMAIL PROTECTED] [2008-03-12 18:20]:
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.
JSON is not a blackbox. (Does that even mean anything?) It's
simply a data format. It's no different from XML in this respect,
it's just a much simpler format than XML that looks exactly like
Javascript (though that doesn't mean you should `eval` it, as
Jonathan said) and deserialises to plain old in-memory Javascript
data structure. Therefore it's much easier to work with on the
client than XML is: you write regular Javascript object/array
accesses instead of painstakingly examining a DOM.
That's it. That's all there is to 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.
The code to send JSON looks pretty much identical.
use JSON::XS;
$c-res-content_type('application/json');
$c-res-body(encode_json($c-stash));
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/
--
do() || do_not(); // try()
Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane
mittam
http://www.kylehultman.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] shared hosting
Here is an example mod_perl apache config. I run a different apache process for every mod_perl cat application I run, and just configure them to work as v-host's - then configure squid to look inward from port 80 and handle the proxy traffic so it's seamless to users. I think at the moment I've got about 15~20 cat apps running on a single xen virtual machine running debian w/ no problems - but it's not under high load so YMMV. VirtualHost *:1181 ServerAdmin [EMAIL PROTECTED] ServerName www.mydomain.tld Alias /static /var/www/www.mydomain.tld/root/static PerlOptions +Parent PerlSwitches -Mlib=/var/www/www.mydomain.tld/lib PerlSwitches -I/var/www/www.mydomain.tld/lib PerlModule CatApp Location / SetHandler modperl PerlResponseHandler CatApp Order allow,deny allow from all /Location DocumentRoot /var/www/www.mydomain.tld/root/static ErrorLog /var/www/www.mydomain.tld/log/error.log LogLevel warn CustomLog /var/www/www.mydomain.tld/log/access.log combined ServerSignature On /VirtualHost On Tue, Mar 4, 2008 at 6:45 PM, Peter Edwards [EMAIL PROTECTED] wrote: From: Jennifer Ahn [mailto:[EMAIL PROTECTED] If my catalyst application is not a stand alone application and contains features to my non-catalyst application. Would that still considered as shared hosting? If I would like to host my catalyst application on the same server as my non-catalyst app, is fast-cgi the best way to do this? The main problem with using mod_perl under Apache is that it's a shared environment. So to run shared hosting you would need one Apache parent per user running either on a different port number or different virtual host. That's one option. Another option, which is easier for development, is to run one FastCGI instance per application area from a single master Apache configuration. In that option, each FastCGI instance has a separate memory space so there's no overlap. For live hosting, I've found that FastCGI goes haywire about once a month and eats CPU until I restart the main Apache server (not been able to track down why), so for production I prefer to use separate Apache instances. Regards, Peter http://perl.dragonstaff.co.uk ___ 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/ -- do() || do_not(); // try() Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane mittam http://www.kylehultman.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: two Catalyst flaws
Message: 7 Date: Thu, 3 Jan 2008 11:27:49 + From: Mike Whitaker [EMAIL PROTECTED] Subject: Re: [Catalyst] two Catalyst flaws To: The elegant MVC web framework catalyst@lists.scsys.co.uk Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed A normal mistake of managing web servers these days is to put tons of web applications onto one server and letting them fight over resources. Servers (and memory in particular) is a low cost factor (compared to development costs). Then why not give your lovely web application some GB's of memory? Absolutely. Memory is cheap, about 1GB / hour of programmer time at any decent rate. (Crucial, 2GB for £52.). If it takes you more than an hour to reduce the memory footprint of your app, buy your server more RAM :) -- I think you may be doing this person a disservice with that advice without first understanding more about what he is trying to accomplish. I can off-hand think of several scenarios where it would be far most cost effective to optimize the memory usage of an application, rather than throwing more memory at the problem; Conversely there are times when it makes sense to just load up more memory. An example I'll throw out is the case of VPS hosting. You have a server, wholly yours, but no physical way of adding RAM to it. Possibly to upgrade the amount of RAM you need to upgrade service (check slicehost.com - that is their business model). So you could see a model of $40/hour or programming to solve for optimizing memory, VS. $40/month for more RAM, estimated 12 months run of project and 4 hours spent on optimization = $160 of programming time to $480 ($40/mo * 12 months) of increased operational cost = $320 net savings. Anyway, I don't know how to fix for the original problem asked, but let's not spit out throw more hardware at the problem, until we understand the problem. -- ___ Catalyst mailing list Catalyst@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst End of Catalyst Digest, Vol 35, Issue 5 *** -- do() || do_not(); // try() Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane mittam http://www.kylehultman.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/
