#typekey

[midnight-drip]

ok expanding on my post from earlier today. spot/katherine thoughts

kath looks up to spot a lot. she thinks it's really cool how spot built brooklyn up from the chaos it was at first, and brought a sort of order and security to its newsies

(shameless plug but if you wanna know more of my headcanons for brooklyn and spot's leadership in general I wrote about it in this fic)

spot in turn respects katherine for her determination and hardworkingness (I don't think that's actually a word but. whatever)

the first time kath watched spot get into a fight, looking at her covered in blood, she thought it was incredibly attractive.

kath is one of the few people who knows spot's birth name (the others are hotshot, jack, lucky, race, and mayyyyybe crutchie) (my personal headcanon is that spot's birth name is "sarah", but I think the more generally accepted name for her is "siobhan"? I'd love to hear other names ppl have for her though)

I think I saw somewhere that katherine would have grown up closer to brooklyn, based on where joseph pulitzer lived? idk I may be wrong. but anyways katherine often observed the brooklyn newsies from her window when she was younger

before the strike, she'd never spoken to spot, but had seen her from the window, mostly in her kinder moments, leading to her having some confusion as to why everyone in manhattan is so scared of her

this one is kind of inspired by the moment in the movie before kony... spot secretly is very excited about having her face and name in the paper. katherine notices this, and she quietly makes sure that in any articles about the newsies in the future, spot gets placed closer to the front for photos so she can be easily seen.

spot rifles through unsold papes for articles written by katherine, and she cuts them up and pins them to a wall in the brooklyn lodging house. when kath notices this, she decides to start buying an extra copy of any papers with her stories, to give to spot at the end of the day.

kath sometimes hangs out in the brooklyn lodging house, she has a super good relationship with most of the newsies, but I will say hotshot at first was a little weird about her (in a "you better not hurt her" kind of way because. spot and hotshot are siblings no matter what. by blood or not it doesn't matter they're sisters)

katherine teaches some of the brooklyn newsies to read when she's around, seeing how good she is with them only makes spot love her more

spot has a lot of freckles which kath will trace patterns on, like constellations. especially the ones on her shoulders

spot WILL sleep on the streets if it means her newsies have a place to sleep in the lodging house. kath gets concerned about this, and tries to convince her to stay with her, but spot is incredibly stubborn. kath and lucky bond over their frustration because they both think it's stupid of her to insist on sleeping outside.

spot, for all her anger and her violent outbursts, is very gentle about every touch when she's with katherine. I headcanon that spot, in her early life, was used a lot, and had relationships, both romantic and otherwise, that were not very good for her, and I think because of that she takes care to treat katherine the best that she can.

umm that's all I have for now thanks for listening to my ramblings :)

[bricas001]

Mapping TypeKey users to a local store in Catalyst

The most common usage of Catalyst’s Authentication framework, is to map a user to a DBIC/CDBI user in a database (via Store::DBIC) .

At my work, we’ve created our own TypeKey server for use as a Signle Sign-On point for all of our internal apps. The TypeKey auth. plugin is by default a storeless credential. Meaning once a user if authenticated a basic hash of information sent back from the TypeKey server will be used as the user information for your app.

This is fine, except that you’ll have no access to the nice Roles and ACL plugins for Authorization that the framework also provides. So, we should strive to integrate Credential::TypeKey with Store::DBIC somehow.

The process initially sounds simple, except for the fact that when a TypeKey authentication comes your app’s way for the first time, the user will not be in your database!

Here’s what I had to do to make everything play nice:

Credential/Store config

I’ll use a snippet of my YAML config file as the example:

authentication: typekey: server : http://typekeyserver.com/ key_url : http://typekeyserver.com/regkeys.txt version : 1 auth_store : default dbic: user_class : MyApp::Model::DBIC::User user_field : username authorization: dbic: role_class : MyApp::Model::DBIC::Role role_field : role role_rel : map_user_role user_role_user_field: user

The main points of interest here are the authentication -> typekey -> auth_store and authentication -> dbic sections. By default the TypeKey plugin doesn’t use an auth store, but Store::DBIC will set itself as the default store, so we need to make that connection. Also, the dbic section only needs information about the user and nothing about passwords since that’s all done remotely on the TypeKey server.

Create our Custom Plugin

Unfortunately, the Store::DBIC plugin expects a user to exist in the database, so in order to make things work the way we want, we’ll have to create our own little plugin that subclasses Store::DBIC.

Your MyApp.pm’s use Catalyst qw(...); section should look something like this:

use Catalyst qw( ... Authentication Authentication::Credential::TypeKey Authentication::Store::DBIC::AutoCreate Authorization::ACL Authorization::Roles ... );

Catalyst::Plugin::Authentication::Store::DBIC::AutoCreate doesn’t exist anywhere on CPAN, so we’ll have to put it in our own lib directory.

This plugin consists of two files:

AutoCreate.pm

package Catalyst::Plugin::Authentication::Store::DBIC::AutoCreate; use strict; use warnings; use base qw( Catalyst::Plugin::Authentication::Store::DBIC ); use Catalyst::Plugin::Authentication::Store::DBIC::AutoCreate::Backend; sub setup { my $c = shift; $c->NEXT::setup(@_); $c->default_auth_store( Catalyst::Plugin::Authentication::Store::DBIC::AutoCreate::Backend->new( { auth => $c->config->{authentication}->{dbic}, authz => $c->config->{authorization}->{dbic} } ) ); } 1;

This will set the default store to an instance of our backend module.

AutoCreate/Backend.pm

package Catalyst::Plugin::Authentication::Store::DBIC::AutoCreate::Backend; use strict; use warnings; use base qw( Catalyst::Plugin::Authentication::Store::DBIC::Backend ); sub get_user { my( $self, $username, $verify, $results ) = @_; my $user = $self->SUPER::get_user( $username ); return $user if $user; $self->config->{ auth }->{ user_class }->create( $results ); $user = $self->SUPER::get_user( $username ); return $user; } 1;

This will let the superclass attempt to get the user as normal. If it fails, then we need to execute a create then re-fetch the user.

Other than that, your user class will have to do something useful with that data passed to the create sub.

Hopefully someone else will find this mini-tutorial useful. :)

[bricas001]

Addendum to TypeKey-Catalyst integration

Since my initial tutorial on integrating TypeKey authentication with local a Catalyst database user, there have been a few significant changes that greatly simplify the process.

The new method requires the latest Catalyst::Plugin::Authentication::Store::DBIC from the svn repository. (Note: A new version of this plugin will soon to be released to CPAN. Watch this space.)

Credential/Store config

The configuration is much the same as before, except for two options: auto_create_user and auto_update_user

authentication: typekey: server : http://typekeyserver.com/ key_url : http://typekeyserver.com/regkeys.txt version : 1 auth_store : default dbic: user_class : Accounts::Account user_field : username auto_create_user: 1 auto_update_user: 1 authorization: dbic: role_class : Accounts::Role role_field : name role_rel : account_roles user_role_user_field: account

Those two options will drive the functionality that we emulated in the old “AutoCreate” plugin.

User Class Modification

The plugin will call auto_create and auto_update on your account class when those events happen.

For auto_create to work, it needs to be called on a ResultSet, so you should use the ResultSetManager in your user class. Each sub gets a number of parameters, the last one being the results of the typekey authentication (a hashref with name, nick, email and ts keys). Use that hashref to add or update the user.

NB: it’s possible for auto_update to get called in situations where it hasn’t authenticated, so it’s important to get out of the process if the data doesn’t exist.

package MyApp::Schema::Account; use strict; use warnings; use base qw( DBIx::Class ); __PACKAGE__->load_components( qw( PK::Auto ResultSetManager Core ) ); # … sub auto_create : ResultSet { my( $self, $username, $req, $res ) = @_; $self->create( { # Deal with $res here } ); } sub auto_update { my( $self, $username, $req, $res ) = @_; return unless $res; # Deal with $res here $self->update; } 1;

That’s it! A much tighter process, don’t you think?

[xerqaespui-blog]

はてなの認証API - まちゅダイアリー (2006-02-25)