Re: [Catalyst] about catalyst authentication
On Saturday 18 April 2009 01:28:30 am Malloy wrote: After restart apache, user must login again. I find $c-user_existsis not true. Why? Because you're using Session::Store::FastMmap and the session cache file didn't exist before your app started, so Cache::FastMmap deletes it on exit? Andrew ___ 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] about catalyst authentication
probably because the session is cleared out On Sat, Apr 18, 2009 at 12:28 AM, Malloy jackwor...@gmail.com wrote: After restart apache, user must login again. I find $c-user_existsis not true. Why? -- Jack Malloy ___ 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/ -- Devin Austin http://www.codedright.net http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost! ___ 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] about catalyst authentication
Thanks. I think so, too. But why Cache::FastMmap deletes it? Where can set
it?
I just use all config default.
use Catalyst qw/-Debug
ConfigLoader::MultiState
Static::Simple
StackTrace
Authentication
Session
Session::Store::FastMmap
Session::State::Cookie/;
Plugin-Authentication.conf:
$default_realm = 'default';
$realms = {
'default' = {
'credential' = {
'class' = 'Password',
'password_field' = 'password',
'password_type' = 'hashed',
'password_hash_type' = 'MD5',
},
'store' = {
'class' = 'DBI',
'user_table' = 'qy_user',
'user_key' = 'id',
'user_name' = 'username',
'user_password' = 'password',
},
},
};
$use_session = 1;
On Sat, Apr 18, 2009 at 2:52 PM, Andrew Rodland arodl...@comcast.netwrote:
On Saturday 18 April 2009 01:28:30 am Malloy wrote:
After restart apache, user must login again. I find $c-user_existsis not
true.
Why?
Because you're using Session::Store::FastMmap and the session cache file
didn't exist before your app started, so Cache::FastMmap deletes it on
exit?
Andrew
___
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/
--
Jack Malloy
___
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] about catalyst authentication
The point is, your sessions are going to be cleared out upon server restart. On Sat, Apr 18, 2009 at 1:10 AM, Malloy jackwor...@gmail.com wrote: Hi Andrew debian:/tmp/qy# ls session_data On Sat, Apr 18, 2009 at 2:52 PM, Andrew Rodland arodl...@comcast.netwrote: On Saturday 18 April 2009 01:28:30 am Malloy wrote: After restart apache, user must login again. I find $c-user_existsis not true. Why? Because you're using Session::Store::FastMmap and the session cache file didn't exist before your app started, so Cache::FastMmap deletes it on exit? Andrew -- Jack Malloy ___ 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/ -- Devin Austin http://www.codedright.net http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost! ___ 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] about catalyst authentication
Yep. but how to fix this problem? On Sat, Apr 18, 2009 at 3:22 PM, Devin Austin devin.aus...@gmail.comwrote: The point is, your sessions are going to be cleared out upon server restart. -- Jack Malloy ___ 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] about catalyst authentication
If your data needs to be more persistent save it in the database On Sat, Apr 18, 2009 at 1:25 AM, Malloy jackwor...@gmail.com wrote: Yep. but how to fix this problem? On Sat, Apr 18, 2009 at 3:22 PM, Devin Austin devin.aus...@gmail.comwrote: The point is, your sessions are going to be cleared out upon server restart. -- Jack Malloy ___ 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/ -- Devin Austin http://www.codedright.net http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost! ___ 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] about catalyst authentication
I find: debian:/tmp/qy# ls session_data debian:/tmp/qy# /etc/init.d/apache2 stop Stopping web server: apache2 ... waiting . debian:/tmp/qy# ls debian:/tmp/qy# The session file is cleared out when apache stop. How to fix this problem? On Sat, Apr 18, 2009 at 3:22 PM, Devin Austin devin.aus...@gmail.comwrote: The point is, your sessions are going to be cleared out upon server restart. -- Jack Malloy ___ 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] about catalyst authentication
I think something is wrong. Please check:
I have two apps wc and qy:
* WC:*
debian:/tmp/wc# /etc/init.d/apache2 start
Starting web server: apache2.
debian:/tmp/wc# ls
session_data
debian:/tmp/wc# /etc/init.d/apache2 stop
Stopping web server: apache2 ... waiting .
debian:/tmp/wc# ls
session_data
*The session_data is there and user needn't login again.*
use Catalyst qw/-Debug
ConfigLoader
Static::Simple
StackTrace
Authentication
Session
Session::Store::FastMmap
Session::State::Cookie/;
authentication
default_realm dbic
realms
dbic
credential
# Note: this first definition would be the same as setting
# __PACKAGE__-config-{authentication}-{realms}-{dbic}
# -{credential} = 'Password' in lib/MyApp.pm
#
# Specify that we are going to do password-based auth
class Password
# This is the name of the field in the users table with the
# password stored in it
password_field password
# Switch to more secure hashed passwords
password_type hashed
# Use the MD5 hashing algorithm
password_hash_type MD5
/credential
store
# Use DBIC to retrieve username, password role information
*class DBIx::Class*
# This is the model object created by Catalyst::Model::DBIC
# from your schema (you created
'MyApp::Schema::Result::User'
# but as the Catalyst startup debug messages show, it was
# loaded as 'MyApp::Model::DB::Users').
# NOTE: Omit 'MyApp::Model' here just as you would when
using
# '$c-model(DB::Users)'
user_class WCDB::WcUser
/store
/dbic
/realms
/authentication
* QY:*
debian:/tmp/qy# /etc/init.d/apache2 start
Starting web server: apache2.
debian:/tmp/qy# ls
session_data
debian:/tmp/qy# /etc/init.d/apache2 stop
Stopping web server: apache2 ... waiting .
debian:/tmp/qy# ls
debian:/tmp/qy#
*
The session_data is cleared out and user must login again.
*use Catalyst qw/-Debug
ConfigLoader::MultiState
Static::Simple
StackTrace
Authentication
Session
Session::Store::FastMmap
Session::State::URI
Session::State::Cookie/;
$default_realm = 'default';
$realms = {
'default' = {
'credential' = {
'class' = 'Password',
'password_field' = 'password',
'password_type' = 'hashed',
'password_hash_type' = 'MD5',
},
'store' = {
* 'class' = 'DBI',*
'user_table' = 'qy_user',
'user_key' = 'id',
'user_name' = 'username',
'user_password' = 'password',
},
},
};
$use_session = 1;
On Sat, Apr 18, 2009 at 3:36 PM, Devin Austin devin.aus...@gmail.comwrote:
If your data needs to be more persistent save it in the database
--
Jack Malloy
___
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] about catalyst authentication
On 18/4/09 09:00, Malloy wrote: I think something is wrong. Please check: Read the docs. http://search.cpan.org/~robm/Cache-FastMmap-1.28/FastMmap.pm If the share_file exists when the process starts it won't be deleted on exit. If it doesn't exist the default is to delete it when the process exits. If you want to be sure of it existing pass undelete_on_exit = 0 to the constructor. S. ___ 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] about catalyst authentication
Thanks all. It's ok now. -- Jack Malloy ___ 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] upon successful login, how do i get redirect users back to the page they wanted to access previously?
On Sat, Apr 18, 2009 at 2:34 AM, kakim...@tpg.com.au wrote:
hi, everybody,
[snip]
upon successful login, how do i get redirect users back to the page they
wanted to access previously (which is
www.lginsurance.com.au/subcriptions/add)? At the moment, upon successful
login, menu.tt2 will be called.
At work we do this with http://tr.im/j75v . If an action requires the
user to be authenticated, they call $c-forward('/user/login'). If
they are logged in, that action returns immediately and the action can
continue. Otherwise, the current URI is stored in session, and the
login form is presented. Then, when the login is successful, the URI
is restored, and the user is redirect.
However... after seeing Devin's approach, which is essentially the
same but without the session, I may change to that. I believe the two
approaches are essentially the same though.
--
Oliver Charles / aCiD2
___
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] Keep getting checksum mismatch problems each time I regenerate my schema files
This discussion should be on the DBIC list really, as it doesn't have much to do with Catalyst. On 17 Apr 2009, at 03:27, kakim...@tpg.com.au wrote: Quoting John Romkey rom...@apocalypse.org: Look in the schema file. You see this line? # DO NOT MODIFY THIS OR ANYTHING ABOVE! md5sum: it means that you modified that line or something above it... Yes I do see the line. If the way the check is to be done is so stringent (ie. permissions on the files it touches or even new lines, surely, the makers of this package could come up with somethign better. I don't have the same issue when using Ruby on Rails' Active Records). What? There is nothing done with permissions, I have no idea what you're talking about with that. And I can't think of a better way to ensure that someone hasn't altered the generated code than what is done. Conceptually you _could_ in some way get the optree of the code, rather than the text, and then checksum that (so that you could add new lines and spaces and comments to the generated code), but this is _extremely non- trivial_ to implement, and also still wouldn't provide a way to leave your modifications in place when the code was re-generated, so I don't see any benefit to investigating it. Saying ActiveRecord doesn't do this isn't really helpful - you're not comparing like with like here.. ActiveRecord does around the same as 'create=dynamic' for schema mode, so there really _is no generated code_, as its introspected each time. You _can_ do your schema like this if you want to, but that opens a whole load of different issues I won't go into here (which ActiveRecord also suffers from). Cheers t0m ___ 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] PAR file - can't build it . Prolly documentation is out of date?
On 17 Apr 2009, at 03:21, kakim...@tpg.com.au wrote: Quoting Tomas Doran bobtf...@bobtfish.net: How do you guys get your PAR files made? We don't. PAR isn't a recommended deployment method these days. K. akimoto: Really?? i would really suggest someone to the mention of it out of the Catalyst cookbook in http://search.cpan.org/~hkclark/Catalyst-Manual-5.7020/lib/Catalyst/ Manual/Cookbook.pod#Quick_deployment:_Building_PAR_Packages. Or more - it shouldn't be taken away, as it is still viable, but there should be more docs on a local::lib approach, and that should be recommended over PAR. This has been noted, and will happen. Cheers t0m ___ 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::Plugin::Session::State::Cookie and HttpOnly flag
On 17 Apr 2009, at 10:37, Scott Thomson wrote: CGI::Simple::Cookie 1.109 (soon to hit the mirrors) now contains support for HttpOnly. You sir, are a bloody legend, good work :) My question now is about the tests for the Catalyst components, I've had a dig through them and I can't see where I would add update them. In Catalyst the only appropriate existing test file is t/live_engine_request_cookies.t which tests the content (the key values) of the cookies but not any of the other config, 'path', 'secure' etc. In C::P::Session::State::Cookie the tests are only concerned with the correct save/restore of the session data, again nothing about the config. Is the assumption that CGI::Simple::Cookie manages that side of things so we don't need to test it in any consumers? or are there missing tests? I'm not trying to get out of supplying tests btw :) I'd go with missing tests. If you're happy to supply tests for your changes, and if you don't mind backfilling a couple of other trivial tests, then that'd be an amazing start! Please feel free to turn up on irc and get a commit bit if you haven't already :) Cheers t0m ___ 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] upon successful login, how do i get redirect users back to the page they wanted to access previously?
Hello, everyone!
thank you for your recommendations.
I have looked at the
http://dev.catalystframework.org/wiki/wikicookbook/nextpageredirect link
and
http://search.cpan.org/~hkclark/Catalyst-Manual-5.7020/lib/Catalyst/Manual/Tutorial/Authentication.pod.
Here's an extract, As discussed in the previous chapter of the
tutorial, flash allows you to set variables in a way that is very
similar to stash, but it will remain set across multiple requests. Once
the value is read, it is cleared (unless reset)..
I tried using FLASH and yet it doesn't work for me.
The value I set in the flash gets lost after a redirect. Sorry to ask
but does flash really work and is it reliable? I know setting stuff in
the session variable is definitely reliable.
Here are some extracts.
1) I access www.lginsurance.com.au/subscriptions/add
2) Since I am not logged in, Root-auto() kicks in and calls Login-index()
3) The path which I am requesting for (being '/subscriptions/add') gets
stored in the flash, $c-flash-{'requested_page'}
4) Looking at the debugging messages printed from Login.pm-, the
$c-flash-{'requested_page'} is empty (ie lost!)
5) The login form appears in my web browser and I log in.
6) All good in that I have authenticated myself but the page that loads
is the main menu (instead of the
page I previously wanted which is
www.lginsurance.com.au/subscriptions/add).
Does flash really work or should I just use the session variable?
Root.pm (start) --
sub auto : Private {
my ($self, $c) = @_;
$c-log-debug( Root.pm - auto and path is . $c-req-path() );
if ($c-controller eq $c-controller('Login')) {
$c-log-debug( Root.pm - auto - asked for login path);
return 1;
}
else{
if ($c-user_exists())
{
my $requested_page = $c-flash-{'requested_page'};
$c-log-debug( Root.pm - auto - USER's logged in.
Proceed.($requested_page));
if ( $requested_page )
{
$c-log-debug( Root.pm - auto - Requested Path is
getting redirected to.);
$c-response-redirect(
$requested_page
);
$c-log-debug( Root.pm - auto - BACK FROM
REDIRECTION... );
}
return 1;
}
else
{
$c-log-debug( Root.pm - auto - USER's not logged in.
Forcing login and setting 'requested_page' = . $c-req-pat
h() );
$c-flash-{'requested_page'} = $c-req-path();
$c-log-debug( Root.pm - auto - USER's not logged in.
RECHECKING THE 'requested_page' = . $c-req-path() );
$c-response-redirect($c-uri_for('/login'));
return 0;
}
}
Root.pm (end ) --
Login.pm (start ) --
sub index : Private {
my ($self, $c) = @_;
$c-log-debug( in login .pm );
my $requested_page = $c-flash-{'requested_page'};
$c-log-debug( Login.pm - index- the path for requested_page is
.($requested_page));
# Get the username and password from form
my $username = $c-request-params-{username} || '';
my $password = $c-request-params-{password} || '';
# If the username and password values were found in form
if ($username $password) {
# Attempt to log the user in
if ($c-login($username, $password))
{
$c-log-debug( Login.pm [authenticated current user] -
index... );
# If successful, then let them use the application
$c-response-redirect( $c-uri_for('/') );
return 1;
}
else
{
# Set an error message
$c-stash-{error_msg} = Bad username or password.;
}
}
# If either of above don't work out, send to the login page
$c-stash-{template} = 'login.tt2';
return 1;
}
Login.pm (end ) --
Quoting Oliver Charles oliver.g.char...@googlemail.com:
On Sat, Apr 18, 2009 at 2:34 AM, kakim...@tpg.com.au wrote:
hi, everybody,
[snip]
upon successful login, how do i get redirect users back to the page
they
wanted to access previously (which is
www.lginsurance.com.au/subcriptions/add)? At the moment, upon
successful
login, menu.tt2 will be called.
At work we do this with http://tr.im/j75v . If an action requires
the
user to be authenticated, they call $c-forward('/user/login'). If
they are logged in, that action returns immediately and the action
can
continue. Otherwise, the current URI is stored in session, and the
login form is presented. Then, when the login is successful, the URI
is restored, and the user is redirect.
However... after seeing Devin's approach, which is essentially the
same but without the session, I may change to that. I believe the
Re: [Catalyst] upon successful login, how do i get redirect users back to the page they wanted to access previously?
Hello, everyone!
I just implemented the change by storing the value of the path that I
wish to access into the session.
It works:)
Nevertheless, I would still like to find out about your thoughts on flash.
Thank you
K. akimoto
Quoting kakim...@tpg.com.au:
Hello, everyone!
thank you for your recommendations.
I have looked at the
http://dev.catalystframework.org/wiki/wikicookbook/nextpageredirect
link
and
http://search.cpan.org/~hkclark/Catalyst-Manual-5.7020/lib/Catalyst/Manual/Tutorial/Authentication.pod.
Here's an extract, As discussed in the previous chapter of the
tutorial, flash allows you to set variables in a way that is very
similar to stash, but it will remain set across multiple requests.
Once
the value is read, it is cleared (unless reset)..
I tried using FLASH and yet it doesn't work for me.
The value I set in the flash gets lost after a redirect. Sorry to
ask
but does flash really work and is it reliable? I know setting stuff
in
the session variable is definitely reliable.
Here are some extracts.
1) I access www.lginsurance.com.au/subscriptions/add
2) Since I am not logged in, Root-auto() kicks in and calls
Login-index()
3) The path which I am requesting for (being '/subscriptions/add')
gets
stored in the flash, $c-flash-{'requested_page'}
4) Looking at the debugging messages printed from Login.pm-, the
$c-flash-{'requested_page'} is empty (ie lost!)
5) The login form appears in my web browser and I log in.
6) All good in that I have authenticated myself but the page that
loads
is the main menu (instead of the
page I previously wanted which is
www.lginsurance.com.au/subscriptions/add).
Does flash really work or should I just use the session variable?
Root.pm (start)
--
sub auto : Private {
my ($self, $c) = @_;
$c-log-debug( Root.pm - auto and path is . $c-req-path()
);
if ($c-controller eq $c-controller('Login')) {
$c-log-debug( Root.pm - auto - asked for login path);
return 1;
}
else{
if ($c-user_exists())
{
my $requested_page = $c-flash-{'requested_page'};
$c-log-debug( Root.pm - auto - USER's logged in.
Proceed.($requested_page));
if ( $requested_page )
{
$c-log-debug( Root.pm - auto - Requested Path
is
getting redirected to.);
$c-response-redirect(
$requested_page
);
$c-log-debug( Root.pm - auto - BACK FROM
REDIRECTION... );
}
return 1;
}
else
{
$c-log-debug( Root.pm - auto - USER's not logged
in.
Forcing login and setting 'requested_page' = . $c-req-pat
h() );
$c-flash-{'requested_page'} = $c-req-path();
$c-log-debug( Root.pm - auto - USER's not logged
in.
RECHECKING THE 'requested_page' = . $c-req-path() );
$c-response-redirect($c-uri_for('/login'));
return 0;
}
}
Root.pm (end )
--
Login.pm (start )
--
sub index : Private {
my ($self, $c) = @_;
$c-log-debug( in login .pm );
my $requested_page = $c-flash-{'requested_page'};
$c-log-debug( Login.pm - index- the path for requested_page
is
.($requested_page));
# Get the username and password from form
my $username = $c-request-params-{username} || '';
my $password = $c-request-params-{password} || '';
# If the username and password values were found in form
if ($username $password) {
# Attempt to log the user in
if ($c-login($username, $password))
{
$c-log-debug( Login.pm [authenticated current user]
-
index... );
# If successful, then let them use the application
$c-response-redirect( $c-uri_for('/') );
return 1;
}
else
{
# Set an error message
$c-stash-{error_msg} = Bad username or password.;
}
}
# If either of above don't work out, send to the login page
$c-stash-{template} = 'login.tt2';
return 1;
}
Login.pm (end )
--
Quoting Oliver Charles oliver.g.char...@googlemail.com:
On Sat, Apr 18, 2009 at 2:34 AM, kakim...@tpg.com.au wrote:
hi, everybody,
[snip]
upon successful login, how do i get redirect users back to the
page
they
wanted to access previously (which is
www.lginsurance.com.au/subcriptions/add)? At the moment, upon
successful
login, menu.tt2 will be called.
At work we do this with http://tr.im/j75v . If an action requires
the
user to be authenticated,
Re: [Catalyst] Jason Kohles' tutorial on ExtJs editable data gridsand Catalyst
Hi Craig,
Thanks a lot for taking the trouble to work through the tutorial. Since you
have been able to get it to save changes to the database, I think we will be
able to isolate where I'm going wrong.
Regarding whether to use 'Catalyst' or 'c' as the context, when I created
the TT view with the Catalyst helper command
'script/adventajaxgrid_create.pl view TT TTSite', it automatically set the
CATALYST_VAR = 'Catalyst'. I changed this to 'c', and the
'Catalyst.uri_for' to 'c.uri_for'. The Ext Grid behaves just like before. It
does everything except the Save.
Can you paste your root/static/advent.js and your View/JSON.pm ? I would
like to compare it with what I have done.
Jagdish
On Sat, Apr 18, 2009 at 1:46 AM, Craig McLaughlin c...@bitbucket.com wrote:
Howdy,
So for grins and giggles I ran through the demo and brute forced it until
it worked (this doesn't imply anything other than I'm not a rocket
scientist with this stuff and that I'm really good at making dumb
mistakes).
I am running the following: ubuntu 8.04, Catalyst 5.71001, ExtJS 2.2.1.
I had to change Catalyst.uri_for to c.uri_for in index.tt2 (I believe you
can also get around this by setting
CATALYST_VAR = 'Catalyst' in your config somewhere. I chose to use 'c' as
that's my default these days.
Other than that, I had a few issues making sure my js functions were in the
right place, but that was it (I am not a .js guy by nature).
I was able to successfully add and edit people, and changes were reflected
in the database [tested by command line:
'sqlite3 advent.db select * from people' ]
If I were in your shoes, I'd probably take another look at getting your
Catalyst / c situation figured out.
Sorry this isn't a direct answer... here's hoping at least a 'here's what I
did and it worked' helps a bit.
Cheers,
--Craig
On Fri, 17 Apr 2009 14:38:43 +0530, jagdish eashwar
jagdish.eash...@gmail.com wrote:
Hi Ian,
I am using ubuntu 8.04 and firefox 2 and no firebug because on my ubuntu
installation firefox 3 hangs and I am unable to install a version of
firebug
that is compatible with firefox 2. In the absence of firebug, I looked
for
the javascript errors in the firefox error log and there were none.
I am hoping that when ubuntu 9.04 is released a little later this month,
I
will be able to start using firefox 3 and firebug.
I am working through Jason Kohle's tutorial on a single computer. It's a
good tutorial and all of it 'just worked' except for saving changes back
to
the database.
On Fri, Apr 17, 2009 at 12:27 PM, Ian Docherty
catal...@iandocherty.comwrote:
jagdish eashwar wrote:
Hi,
No I don't get any javascript error in the error log when I hit
'save',
and it doesn't save the changes in the database either. Just nothing
happens.
This might be obvious to you in which case I apologise, javascript
errors
do not appear in the (server) error log file. You need to check for
errors
client side.
Are you using something like Firefox and FireBug to test your javascript
on
your browser?
Regards
Ian
On Thu, Apr 16, 2009 at 9:34 PM, W. Tyler Gee geek...@gmail.com
mailto:
geek...@gmail.com wrote:
Is there a javascript error when you hit save or is it getting to
the server? Where is your actual problem?
On Thu, Apr 16, 2009 at 5:30 AM, jagdish eashwar
jagdish.eash...@gmail.com mailto:jagdish.eash...@gmail.com
wrote:
Hi Peter,
Thanks for writing in. It is really not my code at all. I have
taken it all from the tutorial. I thought that people will get
a better perspective if I referred them to the tutorial.
Nevertheless, I am pasting code from the advent.js file below.
( I have made a few inconsequential changes though, like the
values in the drop down etc.)
/*
* advent.js
*/
Ext.onReady(function() {
var col_model = new Ext.grid.ColumnModel([
{
id: 'id',
header: 'ID',
dataIndex: 'id',
width: 40
},
{
id: 'name',
header: 'Name',
dataIndex: 'name',
editor: new Ext.form.TextField({
allowBlank: false,
})
},
{
id: 'occupation',
header: 'Occupation',
dataIndex: 'occupation',
width: 70,
editor: new Ext.form.ComboBox({
typeAhead: true,
triggerAction: 'all',
transform: 'occpopup',
lazyRender: true,
listClass:
[Catalyst] [ANNOUNCE] Catalyst Runtime 5.80001
The Catalyst Core Team is proud to announce that we've just shipped the next major release of the Catalyst framework, version 5.8001. This release is the result of the helpful contributions of a large number of people, comprising documentation, new features, bug fixes and entire branches of refactoring, and has taken over twelve months work. Specifically this release would not have been possible without the hard work put in by Guillermo Roditi and Scott McWhirter for the initial port, and Florian Ragwitz on method attributes, as well as their CPAN modules to support this. Huge thanks to those guys, and also to everyone providing patches for documentation, bug fixes, and new features. The major focus of this release is refactoring, and porting to Moose, which enables a lot of additional features, and gives you, the user, a lot of additional power to use when building your applications, and gives the Catalyst team a lot of power for extending the framework. Current applications will still run unmodified, but new code and extensions can start to fully take advantage of Moose. A lot of (previously inadvisable) techniques have become officially deprecated, producing warnings, and full documentation is provided in the distribution to explain any changes which may affect your applications or components. Extensive smoke testing for backwards compatibility has taken place as part of the release process, and we're confident that we haven't broken anything which wasn't a very bad idea in the first place :) The Runtime distributions will be on a CPAN mirror near you before long, but until then you have the option of getting them here: http://files.perldition.org/Catalyst-Runtime-5.80001.tar.gz A further explanation of all the changes can be found in Catalyst::Delta (included below). Thank you for your attention, and for using our software. t0m Full delta from 5.71: Deprecations: Please see Catalyst::Upgrading for a full description of how changes in the framework may affect your application. Below is a brief list of features which have been deprecated in this release: * ::[MVC]:: style naming scheme has been deprecated and will warn NEXT is deprecated for all applications and components, use MRO::Compat Dispatcher methods which are an implementation detail made private, public versions now warn. * MyApp-plugin method is deprecated, use Catalyst::Model::Adaptor instead. * __PACKAGE__-mk_accessors() is supported for backward compatibility only, use Moose attributes instead in new code. * Use of Catalyst::Base now warns New features: Dispatcher - * Fix forwarding to Catalyst::Action objects. * Add the dispatch_type method Restarter - * The development server restarter has been improved to be compatible with immutable Moose classes, and also to optionally use B::Hooks::OP::Check::StashChange to handle more complex application layouts correctly. $c-uri_for_action - Give a private path to the Catalyst action you want to create a URI for. Logging - Log levels have been made additive. Catalyst::Test - * Change to use Sub::Exporter. * Support mocking multiple virtual hosts * New methods like action_ok and action_redirect to write more compact tests Catalyst::Response - * New print method which prints @data to the output stream, separated by $,. This lets you pass the response object to functions that want to write to an IO::Handle. * Added code method as an alias for $res-status Consequences of the Moose back end: * Components are fully compatible with Moose, and all Moose features, such as method modifiers, attributes, roles, BUILD and BUILDARGS methods are fully supported and may be used in components and applications. * Many reusable extensions which would previously have been plugins or base classes are better implemented as Moose roles. * MooseX::MethodAttributes::Inheritable is used to contain action attributes. This means that attributes are represented in the MOP, and decouples action creation from attributes. * There is a reasonable API in Catalyst::Controller for working with and registering actions, allowing a controller sub- class to replace subroutine attributes for action declarations with an alternate syntax. * Refactored capturing of $app from Catalyst::Controller into Catalyst::Component::ApplicationAttribute for easier reuse in other components. * Your application class is forced to become immutable at the end of compilation. Bug fixes: * Don't ignore SIGCHLD while handling requests with the
Re: [Catalyst] [ANNOUNCE] Catalyst Runtime 5.80001
2009/4/18 Tomas Doran bobtf...@bobtfish.net The Catalyst Core Team is proud to announce that we've just shipped the next major release of the Catalyst framework, version 5.8001. This release is the result of the helpful contributions of a large number of people, comprising documentation, new features, bug fixes and entire branches of refactoring, and has taken over twelve months work. Woot! Nice work, I'm very impressed. 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/
Re: [Catalyst] upon successful login, how do i get redirect users back to the page they wanted to access previously?
On Sat, Apr 18, 2009 at 10:19 PM, kakim...@tpg.com.au wrote:
Hello, everyone!
thank you for your recommendations.
I have looked at the
http://dev.catalystframework.org/wiki/wikicookbook/nextpageredirect link
and
http://search.cpan.org/~hkclark/Catalyst-Manual-5.7020/lib/Catalyst/Manual/Tutorial/Authentication.podhttp://search.cpan.org/%7Ehkclark/Catalyst-Manual-5.7020/lib/Catalyst/Manual/Tutorial/Authentication.pod
.
Here's an extract, As discussed in the previous chapter of the
tutorial, flash allows you to set variables in a way that is very
similar to stash, but it will remain set across multiple requests. Once
the value is read, it is cleared (unless reset)..
I tried using FLASH and yet it doesn't work for me.
The value I set in the flash gets lost after a redirect. Sorry to ask
but does flash really work and is it reliable? I know setting stuff in
the session variable is definitely reliable.
Here are some extracts.
1) I access www.lginsurance.com.au/subscriptions/add
2) Since I am not logged in, Root-auto() kicks in and calls
Login-index()
3) The path which I am requesting for (being '/subscriptions/add') gets
stored in the flash, $c-flash-{'requested_page'}
4) Looking at the debugging messages printed from Login.pm-, the
$c-flash-{'requested_page'} is empty (ie lost!)
5) The login form appears in my web browser and I log in.
6) All good in that I have authenticated myself but the page that loads
is the main menu (instead of the
page I previously wanted which is
www.lginsurance.com.au/subscriptions/add).
Does flash really work or should I just use the session variable?
Root.pm (start) --
sub auto : Private {
my ($self, $c) = @_;
$c-log-debug( Root.pm - auto and path is . $c-req-path() );
if ($c-controller eq $c-controller('Login')) {
$c-log-debug( Root.pm - auto - asked for login path);
return 1;
}
else{
if ($c-user_exists())
{
my $requested_page = $c-flash-{'requested_page'};
$c-log-debug( Root.pm - auto - USER's logged in.
Proceed.($requested_page));
if ( $requested_page )
{
$c-log-debug( Root.pm - auto - Requested Path is
getting redirected to.);
$c-response-redirect(
$requested_page
);
$c-log-debug( Root.pm - auto - BACK FROM
REDIRECTION... );
}
return 1;
}
else
{
$c-log-debug( Root.pm - auto - USER's not logged in.
Forcing login and setting 'requested_page' = . $c-req-pat
h() );
$c-flash-{'requested_page'} = $c-req-path();
$c-log-debug( Root.pm - auto - USER's not logged in.
RECHECKING THE 'requested_page' = . $c-req-path() );
$c-response-redirect($c-uri_for('/login'));
return 0;
}
}
Root.pm (end ) --
Login.pm (start ) --
sub index : Private {
my ($self, $c) = @_;
$c-log-debug( in login .pm );
my $requested_page = $c-flash-{'requested_page'};
$c-log-debug( Login.pm - index- the path for requested_page is
.($requested_page));
# Get the username and password from form
my $username = $c-request-params-{username} || '';
my $password = $c-request-params-{password} || '';
# If the username and password values were found in form
if ($username $password) {
# Attempt to log the user in
if ($c-login($username, $password))
{
$c-log-debug( Login.pm [authenticated current user] -
index... );
# If successful, then let them use the application
$c-response-redirect( $c-uri_for('/') );
return 1;
}
else
{
# Set an error message
$c-stash-{error_msg} = Bad username or password.;
}
}
# If either of above don't work out, send to the login page
$c-stash-{template} = 'login.tt2';
return 1;
}
Login.pm (end ) --
Quoting Oliver Charles oliver.g.char...@googlemail.com:
On Sat, Apr 18, 2009 at 2:34 AM, kakim...@tpg.com.au wrote:
hi, everybody,
[snip]
upon successful login, how do i get redirect users back to the page
they
wanted to access previously (which is
www.lginsurance.com.au/subcriptions/add)? At the moment, upon
successful
login, menu.tt2 will be called.
At work we do this with http://tr.im/j75v . If an action requires
the
user to be authenticated, they call $c-forward('/user/login'). If
they are logged in, that action returns immediately and the action
can
continue. Otherwise, the current URI is stored in session, and the
login form is presented. Then, when the login is successful, the URI
Re: [Catalyst] [ANNOUNCE] Catalyst Runtime 5.80001
Tremendous thanks and am looking forward to 5.9 :) --John Napiorkowski --- On Sat, 4/18/09, Tomas Doran bobtf...@bobtfish.net wrote: From: Tomas Doran bobtf...@bobtfish.net Subject: [Catalyst] [ANNOUNCE] Catalyst Runtime 5.80001 To: The elegant MVC web framework catalyst@lists.scsys.co.uk Date: Saturday, April 18, 2009, 4:28 PM The Catalyst Core Team is proud to announce that we've just shipped the next major release of the Catalyst framework, version 5.8001. This release is the result of the helpful contributions of a large number of people, comprising documentation, new features, bug fixes and entire branches of refactoring, and has taken over twelve months work. Specifically this release would not have been possible without the hard work put in by Guillermo Roditi and Scott McWhirter for the initial port, and Florian Ragwitz on method attributes, as well as their CPAN modules to support this. Huge thanks to those guys, and also to everyone providing patches for documentation, bug fixes, and new features. The major focus of this release is refactoring, and porting to Moose, which enables a lot of additional features, and gives you, the user, a lot of additional power to use when building your applications, and gives the Catalyst team a lot of power for extending the framework. Current applications will still run unmodified, but new code and extensions can start to fully take advantage of Moose. A lot of (previously inadvisable) techniques have become officially deprecated, producing warnings, and full documentation is provided in the distribution to explain any changes which may affect your applications or components. Extensive smoke testing for backwards compatibility has taken place as part of the release process, and we're confident that we haven't broken anything which wasn't a very bad idea in the first place :) The Runtime distributions will be on a CPAN mirror near you before long, but until then you have the option of getting them here: http://files.perldition.org/Catalyst-Runtime-5.80001.tar.gz A further explanation of all the changes can be found in Catalyst::Delta (included below). Thank you for your attention, and for using our software. t0m Full delta from 5.71: Deprecations: Please see Catalyst::Upgrading for a full description of how changes in the framework may affect your application. Below is a brief list of features which have been deprecated in this release: * ::[MVC]:: style naming scheme has been deprecated and will warn NEXT is deprecated for all applications and components, use MRO::Compat Dispatcher methods which are an implementation detail made private, public versions now warn. * MyApp-plugin method is deprecated, use Catalyst::Model::Adaptor instead. * __PACKAGE__-mk_accessors() is supported for backward compatibility only, use Moose attributes instead in new code. * Use of Catalyst::Base now warns New features: Dispatcher - * Fix forwarding to Catalyst::Action objects. * Add the dispatch_type method Restarter - * The development server restarter has been improved to be compatible with immutable Moose classes, and also to optionally use B::Hooks::OP::Check::StashChange to handle more complex application layouts correctly. $c-uri_for_action - Give a private path to the Catalyst action you want to create a URI for. Logging - Log levels have been made additive. Catalyst::Test - * Change to use Sub::Exporter. * Support mocking multiple virtual hosts * New methods like action_ok and action_redirect to write more compact tests Catalyst::Response - * New print method which prints @data to the output stream, separated by $,. This lets you pass the response object to functions that want to write to an IO::Handle. * Added code method as an alias for $res-status Consequences of the Moose back end: * Components are fully compatible with Moose, and all Moose features, such as method modifiers, attributes, roles, BUILD and BUILDARGS methods are fully supported and may be used in components and applications. * Many reusable extensions which would previously have been plugins or base classes are better implemented as Moose roles. * MooseX::MethodAttributes::Inheritable is used to contain action attributes. This means that attributes are represented in the MOP, and decouples action creation from attributes. * There is a reasonable API in Catalyst::Controller for working with and registering actions, allowing a controller sub-class to replace subroutine attributes for action declarations with an alternate
Re: [Catalyst] What's the best way to exclude static requests from needing user to log in?
On Sun, Apr 19, 2009 at 9:06 AM, kakim...@tpg.com.au wrote:
hi, all
what's the best way to exclude static requests from needing the user
to log in?
Some parts of my site are open to general public. For example, the
'contact us', 'services portfolio' and so forth pages.
At the moment, I have put in codes in my MyApp::Controller::Root-auto
and it seems to want every request to be logged on.
Hence, identifying which path requests are for my static pages, I have
put in a filter in the MyApp::Controller::Root-auto method to return a
1 and not go further.
Any better way around this? Another way is to have specific methods in
controllers themselves (any CRUD method) checking if the user was
logged on each time they request a controller action that requires
authentication.
Anyway, here's the source code. Hope it makes sense and thanks, everyone!
-- extract - MyApp::Controller::Root-auto method
(start) --
sub auto : Private {
my ($self, $c) = @_;
# filter out the static requsts
if ( $c-request-path() =~
m{^(sign_up|subscription_plans|services_portfolio|company_profile|contact_us)$}smx
)
{
return 1;
}
elsif ($c-controller eq $c-controller('Login') or
$c-controller eq $c-controller('Logout')) {
return 1;
}
else{
unless ($c-user_exists())
{
$c-log-debug( Root.pm - auto - USER's not logged in.
Forcing login and setting 'requested_page' = . $c-req-path() );
myApp::Controller::Shared-store_in_session ($c,
{ 'requested_page' = $c-req-path(), }
);
$c-response-redirect($c-uri_for('/login'));
return 0;
}
return 1;
}
-- extract - MyApp::Controller::Root-auto method (end)
--
I can think of several ways, the best being to use the ACL plugin, since
this is what it is for. Drop the auto action determining what is necessary
and catch the auth errors in /end and handle accordingly.
Or, you could use Chained and have a root chain that requires authentication
(or, conversely, one that doesn't) and link that way. This would be the
second best, in my opinion, but seeing that you aren't building your
application with Chained you probably aren't going to switch.
The way with your current code that I would do it is to define a
configuration key in your controller, like __PACKAGE__-config({
require_login = 0 });
Then you can modify your Root::auto method, and add in something like this:
if ( defined $c-controller-{require_login} and
$c-controller-{require_login} == 0 ) {
return 1;
}
This, by default, would assume the user is required to login but then would
look at the controllers for the individual requirements.
Still a bit dirty, but not that intrusive.
-J
___
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] Jason Kohles' tutorial on ExtJs editable data gridsand Catalyst
jagdish eashwar wrote: Hi Craig, Thanks a lot for taking the trouble to work through the tutorial. Since you have been able to get it to save changes to the database, I think we will be able to isolate where I'm going wrong. Regarding whether to use 'Catalyst' or 'c' as the context, when I created the TT view with the Catalyst helper command 'script/adventajaxgrid_create.pl view TT TTSite', it automatically set the CATALYST_VAR = 'Catalyst'. I changed this to 'c', and the 'Catalyst.uri_for' to 'c.uri_for'. The Ext Grid behaves just like before. It does everything except the Save. Can you paste your root/static/advent.js and your View/JSON.pm ? I would like to compare it with what I have done. Did you try commenting out the 'console.log' line as someone else suggested? ___ 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] What's the best way to exclude static requests from needing user to log in?
On Apr 18, 2009, at 8:06 PM, kakim...@tpg.com.au wrote: hi, all what's the best way to exclude static requests from needing the user to log in? The best way to exclude static requests from needing the user to log in is to not run them through Catalyst at all. Configure your web server so that static files are served directly by the server. This will greatly improve performance as well as simplify your Catalyst code. Unless that's not what you mean by static. If you by static you still mean some dynamic content, I would strongly avoid putting all the logic for access control in Root's auto method. Root's auto method then knows too much about the implementation details of each controller. Instead put the access control logic where it belongs - with the stuff it's controlling access to. - john romkey http://www.romkey.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] What's the best way to exclude static requests from needing user to log in?
hi,John, Good arvo. Thanks for the comments. My replies are as per below: Quoting John Romkey rom...@apocalypse.org: On Apr 18, 2009, at 8:06 PM, kakim...@tpg.com.au wrote: hi, all what's the best way to exclude static requests from needing the user to log in? The best way to exclude static requests from needing the user to log in is to not run them through Catalyst at all. Configure your web server so that static files are served directly by the server. This will greatly improve performance as well as simplify your Catalyst code. K. akimoto: You have a very good point and I think I will consider this. Unless that's not what you mean by static. If you by static you still mean some dynamic content, I would strongly avoid putting all the logic for access control in Root's auto method. Root's auto method then knows too much about the implementation details of each controller. Instead put the access control logic where it belongs - with the stuff it's controlling access to. - john romkey http://www.romkey.com/ K. akimoto: this is interesting. All requests would have to go through Root-auto before any other actions in controllers Hence, whilst the Root-auto method does hold implementation details of all controllers in the application, it certainly makes future maintaince of the application ( in terms of controlling all controller access ) easier because the configuration is found in one spot rather than all across the many controllers. Is doing so a bad practice? I would really like to hear some good discussions here.. Thank you again, John :) K. akimoto ___ 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] Jason Kohles' tutorial on ExtJs editable data gridsand Catalyst
Hi Peter, Scott and Craig, Thanks a lot. Commenting out 'console.log' worked. It works irrespective of whether I use 'Catalyst.uri_for' or 'c.uri_for'. I guess that line can be there only if one is using firebug. And I think the tutorial code worked for Craig because he was using firebug. Is that right Craig? Thanks to Scott for being so perceptive and to Peter for being persistent. Jagdish On Sun, Apr 19, 2009 at 7:53 AM, Peter Karman pe...@peknet.com wrote: jagdish eashwar wrote: Hi Craig, Thanks a lot for taking the trouble to work through the tutorial. Since you have been able to get it to save changes to the database, I think we will be able to isolate where I'm going wrong. Regarding whether to use 'Catalyst' or 'c' as the context, when I created the TT view with the Catalyst helper command 'script/adventajaxgrid_create.pl view TT TTSite', it automatically set the CATALYST_VAR = 'Catalyst'. I changed this to 'c', and the 'Catalyst.uri_for' to 'c.uri_for'. The Ext Grid behaves just like before. It does everything except the Save. Can you paste your root/static/advent.js and your View/JSON.pm ? I would like to compare it with what I have done. Did you try commenting out the 'console.log' line as someone else suggested? ___ 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/
