gmane.comp.web.catalyst.general

Re: Catalyst::Test Plack and HTTP Auth

Alejandro Imass — 2012-05-24T20:47:16

On Thu, May 24, 2012 at 2:02 PM, Alejandro Imass
<alejandro.imass< at >gmail.com> wrote:

I can confirm it works perfectly! With Catalyst::Test you can do most
of the stuff you can do w/ a regular ua (plain lap, mech and even
mech::cat). Below is an example of how I got it working. In this
example I'm testing a JSON-only API so it should get 415 if
content-type and accept are not JSON:

# correct auth, wrong content-type test
$h = HTTP::Headers->new(
  'Content-Type' => 'text/html; charset=utf-8',
  'Accept' => 'text/html; charset=utf-8',
);
$h->authorization_basic('apiuser','user1234');
$req = HTTP::Request->new(
  POST => '/smsrstgw', $h
);
$ret = request($req);
ok($ret->code == 415);





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

Re: Catalyst::Test Plack and HTTP Auth

Alejandro Imass — 2012-05-24T18:02:06

On Thu, May 24, 2012 at 1:53 PM, Alejandro Imass
<alejandro.imass< at >gmail.com> wrote:

Update: I think I found a way by using HTTP::Request object instead of
the URI and then HTTP::Headers object inside that with the auth
headers and that _should_ work. Will post follow-up here if it
actually works.....




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

Catalyst::Test Plack and HTTP Auth

Alejandro Imass — 2012-05-24T17:53:08

Hello,

Is it possible to set the auth headers with the Plack stuff w/o having
to do the base64 and set headers manually?
I.e. something like with mech:

$mech->credentials( $username, $password );

But using the Catalyst::Test way...

Thanks!

Re: Role problems, Still

Kenneth S Mclane — 2012-05-24T15:24:12

Yes, I meant the authentication. I'm adding code right after 
authentication to check for existence if the user in the db, adding them 
if not as well as assigning the default role then I want to store the list 
of roles in the session so I can control access. Working my way through 
it. 

Tomas Doran <bobtfish< at >bobtfish.net> wrote on 05/24/2012 10:06:33 AM:

http://www.mail-archive.com/catalyst< at >lists.scsys.co.uk/

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

Re: Changing Formhandler field-type/widget based onCatalyst user-role

will trillich — 2012-05-24T15:28:06

Hmm. Still puzzled as to what solution might work with that approach. Maybe
changing-field-type is philosophically questionable, but the mechanism
still looks like it should work. :) But didn't.

So we're off to try more FormHandler magic from a different angle (not
catalyst-affected, so we're posting on the formhandler list for that).



On Thu, May 24, 2012 at 3:46 AM, Denny <2012< at >denny.me> wrote:

Re: Role problems, Still

Tomas Doran — 2012-05-24T15:06:33

On 24 May 2012, at 13:45, Kenneth S Mclane wrote:


Erm? The role checking _is_ the authorisation??

You mean 'the authentication'?

And I'm not suggesting you re-invent it… I was suggesting you continue to do it from LDAP?


sure, you can just subclass the user class with your own user class to override the 'roles' method, and the 'for_session' and 'from_session' methods to do what you want.

Cheers
t0m
 
_______________________________________________
List: Catalyst< at >lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst< at >lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: Role problems, Still

Kenneth S Mclane — 2012-05-24T12:45:45

Well since the passwords are maintained by a company wide system and can 
be authenticated via LDAP, I don't think I want to reinvent the 
authorization, since it is working. I think I will just reinvent the role 
checking, which should be much simpler. My question is: can I store the 
role information in the user session? I'll be reading up on that today. 
Maybe one day I'll get ambitious and figure out how to do it the way I 
wanted to.

Tomas Doran <bobtfish< at >bobtfish.net> wrote on 05/23/2012 11:04:52 AM:

http://www.mail-archive.com/catalyst< at >lists.scsys.co.uk/

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

Re: Changing Formhandler field-type/widget based onCatalyst user-role

Denny — 2012-05-24T08:46:28

Short answer; don't.

If you're maintaining the value for users who aren't allowed to change
it, then you don't want it in your form data.  Form submissions can be
spoofed, so you'd have to double-check the value (or drop it) in your
Perl code anyway... so you might as well just do that, and remove it
entirely from the HTML (which seems to be a simpler problem?)

Regards,
Denny



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

Changing Formhandler field-type/widget based on Catalystuser-role

will trillich — 2012-05-24T04:24:43

Short version: How can we toggle field "X" from being a Select (popup) for
Admin users, to being a Hidden (nothing visible, but the value is
maintained) for Manager users?

Long version:

We have three levels of user-roles (*admins* can do everything,
*managers*can do a lot,
*readonly* can do very little). Admins get to specify user roles for all
users (even other admins), but managers (level two) only get to edit
readonly users and we don't want them to elevate any such users to being
managers (or worse, admins).

    package MyApp::Controller::Admin::Person;
    #...
    $self->form( MyApp::Form::Admin::Person->new( ctx => $c ) );

    package MyApp::Form::Admin::Person;
    #....
    sub set_active {
        my $self = shift;
        $self->inactive(['role'])
            unless $self->ctx->user->is_admin;
    }

Trying to use ctx so we could pass $c and later test it in the form's
"set_active" method throws an exception because of ctx being undefined.

    package MyApp::Controller::Admin::Person;
    #...
    unless ( $c->user->is_admin ) {
#       $self->form->inactive(['role']);
#       $self->form->field('role')->widget('hidden');
#       $self->form->field('role')->type('Hidden');
    }

So instead we've tried making the field inactive (no apparent effect at
all), switching to a different widget (field completely disappears) or
different type (field completely disappears).

Pointers?

Re: Module::Install::Catalyst and Test::Prereqs conflict?

Robert Rothenberg — 2012-05-23T17:49:16

I can't figure out form a brief look at the source what might be causing it,
and asked on this list in case anyone else has come across the problem.


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

Re: Module::Install::Catalyst and Test::Prereqs conflict?

Tomas Doran — 2012-05-23T17:42:13

On 23 May 2012, at 17:15, Robert Rothenberg wrote:


So nothing?

Cheers
t0m


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

Re: Module::Install::Catalyst and Test::Prereqs conflict?

Robert Rothenberg — 2012-05-23T16:15:23

It occurs in some of the other modules that do the same thing, such as
Module::CPANTS::Kwalalitee::Prereq.


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

Re: Module::Install::Catalyst and Test::Prereqs conflict?

Tomas Doran — 2012-05-23T16:06:39

On 23 May 2012, at 11:26, Robert Rothenberg wrote:


What leads you to suspect that this is anything to do with Module::Install::Catalyst?

I'd have guessed at a bug between Test::Prereqs and Module::Install itself, rather than the Catalyst specific extension..

Cheers
t0m


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

Re: Role problems, Still

Tomas Doran — 2012-05-23T16:04:52

On 23 May 2012, at 16:37, Kenneth S Mclane wrote:


In this case, I would be using the DBIC authentication store module (not the LDAP one), with the self_check Credential option + the auto_create_user option, and writing a check_password method (yourself) which looked up the user in LDAP and did the auth there…

If you want roles and other foreign keys etc - then you want the user row from DBIC to be master, and authentication to just be delegated down to that row instance..

Cheers
t0m


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

Role problems, Still

Kenneth S Mclane — 2012-05-23T15:37:43

I am having difficulty in getting my user to authenticate against the 
second realm. After successfully authenticating against the ldap server, I 
want to authenticate against the dbic realm as well as that is where the 
roles are stored. It seems to ignore a second call to $c-.authenticate.

I tried removing the "default_realm => 'ldap'" entry but it complained 
with an error of not find the user in the realm "default". 

I looked at the "Progressive" module, but it seems to me that it stops as 
soon as the user authenticates.

I also have had no luck doing a find_or_create. Do I need to consolidate 
the roles into the users table? 

I even tried just creating a user in the user table figuring I could do a 
second step of updateing the users_to_roles table after that. I keep 
getting "me.user is not valid in the context it is being used"

Once again I can find no help in the docs. They simply do not address this 
situation. I have found that other people have solved this, but they don't 
seem to post the code that solved it, just something along the lines of "I 
fixed it". That isn't of much help to us new folks.


Any help is appreciated._______________________________________________
List: Catalyst< at >lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst< at >lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: Plugin::Session lazy start

Ashley Pond V — 2012-05-23T14:58:21

On Wed, May 23, 2012 at 7:42 AM, Alexander Hartmaier
<alexander.hartmaier< at >t-systems.at> wrote:

I think this is generally excellent advice but I want to argue against
it in this case.

UID => sub { $< } is sufficiently semantic *and* edifying. E.g., Oh!
That's the special var for UID. It finally makes sense.

use English;
UID => sub { $UID } is redundant to point of being annoying and even
distracting (to me).

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

Re: Plugin::Session lazy start

Dag-Erling Smørgrav — 2012-05-23T14:54:50

assuming "use English"

DES

Re: Plugin::Session lazy start

Dag-Erling Smørgrav — 2012-05-23T14:51:29

I was wrong about that last bit - unlink_on_exit automatically defaults
to a sane value (unlink the file if you created it, leave it alone if it
already existed).  If anything, you'd want to set it to 0 so sessions
are persistent across server restarts.

BTW, this is not a perfect solution, since all processes owned by the
same user will now share a session cache.  However, this should rarely
(if ever) be a problem.

DES

Re: Plugin::Session lazy start

Alexander Hartmaier — 2012-05-23T14:42:25

Because I've just read perlvar: $REAL_USER_ID or $UID instead of $<.

- Alex


Am 2012-05-23 15:54, schrieb Ashley Pond V:


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*

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

Re: Plugin::Session lazy start

Dag-Erling Smørgrav — 2012-05-23T14:35:40

Thanks, that's a neat workaround (combined with unlink_on_exit).

DES

sort %hash in TT with Catalyst

Tomasz Gromowski — 2012-05-23T13:53:13

Hello,
how can I sort hash reference by values, I found some solution:
http://mail.template-toolkit.org/pipermail/templates/2005-June/007501.html
But I  don't know where can I add virtual method.

3) Similar to 2. Add a virtual method to your hashes. Just add this above your process call. (Note: You might need to add: 'use Template::Stash;') :
$Template::Stash::HASH_OPS->{ sort_keys_by } = sub {
   my ($hash, $sort_field) = < at >_;
     return sort {
        $hash->{$a}->{$sort_field}<=>  $hash->{$b}->{$sort_field}
     } keys %$hash
};

then you can do:
[% FOREACH r = ref.sort_keys_by('number') %]
<a href="/program?id=[% r %]">[% ref.$r.title _ " " _ ref.$r.number %]</a>
[% END %]


I try to add virtual method to  View  but i get error:

|Couldn't render template "stats.tt: undef error - Can't use string ("1") as a HASH ref while "strict refs" in use at View/HTML.pm line 15.|




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