idea - Class::Data::Separated
This is just an idea at the moment, and mainly I'm wondering if this kind of thing already exists? I'm debugging a mod_perl app just now, so I'm using Apache::Reload to allow me to edit modules and have them automatically reload without having to restart the server. Works very nicely, except when a module has associated class data. The data are all lost when the module reloads, so I end up having to restart the server after all. Partly I'm addressing this by refactoring some code out into modules that have no class data. The logical extension to this would be to provide a module that stores class data for other classes, so there's only ever one module that is really storing any class data. I'm thinking that a client module could set and retrieve its classdata into the helper class, which does a lookup based on the caller to locate the caller's class data, which it returns. Then I can safely mess with the code in the caller and not lose its class data. I generally use Class::Data::Inheritable to manage class data, and my first thought would be to base this thing on that, so it might be called Class::Data::Inheritable::Separated, or else just Class::Data::Separated. Is this wheel already spinning somewhere? Cheers, d. -- Dr. David R. Baird Riverside Content Management Systems http://www.riverside-cms.co.uk
Re: [RFC] Apache::Session::Memcached - new module proposal
Looks good. Can I suggest that the 'servers' option takes a data
structure, rather than a single formatted string? Something like
tie %session, 'Apache::Session::Memcached', $sid, {
Servers = { '10.0.0.1' = '2',
'10.0.0.2' = '2',
}
};
d.
On 13 Sep 2004 at 19:37, Enrico Sorcinelli wrote:
Hi all,
I just realized Apache::Session::Memcached, a simple module that stores
persistent data using memcached (and his Cache::Memcached Perl API) for
Apache::Session storage.
It's available for evaluating and testing at:
http://modperl.it/Apache-Session-Memcached-0.01.tar.gz
I've attached a temporary POD at the end of the message.
I searched on CPAN and I've not found any similar module (the reason why I wrote
it).
Since I would put it on CPAN, any suggestions about the module and/or namespace
are welcome.
Thanks in advance
by
- Enrico
---
=head1 NAME
Apache::Session::Memcached - Stores persistent data using memcached (memory
cache daemon) for Apache::Session storage
=head1 SYNOPSIS
use Apache::Session::Memcached;
tie %session, 'Apache::Session::Memcached', $sid, {
Servers = '10.0.0.1:2 10.0.0.2:2',
};
tie %size_aware_session, 'Apache::Session::Memcached', $sid, {
Servers = '10.0.0.1:2 10.0.0.2:2',
};
=head1 DESCRIPTION
Apache::Session::Memcached is a bridge between Apache::Session and
memcached, a distributed memory cache daemon.
More informations about memcached are available at
Lhttp://www.dunga.com/memcached.
This module provides a way to use Cache::Memcached (memcached Perl API) as
Apache::Session storage implementation.
=head1 NOTE
This is a alpha release.
Docs and some code checks must be improved.
=head1 SEE ALSO
LApache::Session|Apache::Session,
LApache::Session::Flex|Apache::Session::Flex,
LCache::Memcached|Cache::Memcached, Lmemcached.
=head1 AUTHOR
Enrico Sorcinelli Eltenrico at sorcinelliEgt
=head1 COPYRIGHT AND LICENSE
Copyright (C) 2004 by Enrico Sorcinelli
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself, either Perl version 5.8.1 or,
at your option, any later version of Perl 5 you may have available.
=cut
--
Dr. David R. Baird
Riverside Content Management Systems
http://www.riverside-cms.co.uk
Re: namespace for users and groups
I've just uploaded the first version of Tree::Authz to the CPAN, I'd be very interested in any comments people might have. Does it seem useful, does it violate expectations, how does the API grab you? Cheers, d. -- Dr. David R. Baird Riverside Content Management Systems [EMAIL PROTECTED] http://www.riverside-cms.co.uk
Re: Name space and module list
On 26 Aug 2004 at 15:21, [EMAIL PROTECTED] wrote: [snippety snip] As I already hinted at, I don't like lengthy discussion so don't expect me arguing and (dis)agreeing too much over opinion expressions following this mail. OK. d. -- Dr. David R. Baird Riverside Content Management Systems http://www.riverside-cms.co.uk
Re: namespace for users and groups
On 24 Aug 2004 at 11:32, Sam Vilain wrote: Group, by itself, infers no such treeness. You may have chosen to model your groups and users by some close analogue of; +-+ +-+ ++ | GrantableEntity |--| Grant |--| Entity | +++ 1 * +-+ * 1 ++ /_\ | +---+ +-++ | | * | | |* +-+ * * ++ +--| Group |-| User | +-+ ++ Unix Groups, for instance, do not bother with this, so Group doesn't mean Heirarchy of Groups in this case. Yes, I see that. So I'm building one particular model of an ACL, so the module name should refer to that, so Tree is more relevant than Group in the name. My model would be more like (UML neophyte diagram coming up): +-+ | GrantableEntity | +++ * | | +---+ +-+ | | * | |* +-+ 1 * ++ +--| Group |-| User | +-+ ++ What I mean is, groups contain subgroups to arbitrary depth, groups have things they can grant, these things can be strings, coderefs, or methods, and users always have to go through their (probably single) group to get at their GrantableEntities. I don't think my module says anything about the relationship between grants and the entities they protect. I think you create these yourself and store them on the nodes of the tree. Having heard a little about various ACL schemes here, and skimmed a few of the Authen:: modules on CPAN, I doubt if my module will be much use for, say, plugging into an existing ACL framework or service. They have their model, I have mine. But if you have a multiuser app and you need a straightforward means of splitting users up and assigning access permissions to different aspects of your app, then my module, hopefully, would be an option. [...] UML is an excellent language with which to express the exact nature of the ACL that your module implements. _*The Art of Objects: Object-Oriented Design and Architecture_, by *Yun-Tung Lau http://www.amazon.com/exec/obidos/search-handle-url/index=booksfield-author=Yun-Tung%20Lau/102-5857950-6496945 (isbn://0201711613/) uses ACL design as one of its worked examples. Highly recommended. I had a lot of fun a few months back using UML for the first time to design things properly, it's a powerful tool, I'm still seeing the benefits today. I've been looking for the next textbook to read, looks like I've just found it! Examples in a domain you are actually working in are always great. I've applied to register the namespace Tree::Authz on PAUSE. A name can never communicate everything about a module, but I think that covers the essentials. A huge improvement over Admin::Group! Cheers, d. -- Dr. David R. Baird Riverside Content Management Systems [EMAIL PROTECTED] http://www.riverside-cms.co.uk
Re: namespace for users and groups
On 22 Aug 2004 at 22:31, david nicol wrote: On Sun, 2004-08-22 at 18:04, David R. Baird wrote: I'm not 100% sure of the Tree:: bit (although it is based on a tree structure), but I can't see where else it could fit in. d. Are the arboreal aspects important to the use of the tool or are they implementation details? Could you change it to use a hash or a SQL server without altering the interface? Ifyou did, would it make said arbitrary back-end appear treelike? I think the treeness is quite important, because groups inherit the capabilities/permissions of their subgroups. So whenever you check if your own group is permitted to do something, you know that the tree- like hierarchy of groups contained within your group is also being checked. The treeness isn't apparent when you do an authorization lookup (you just query against your own group), but it is apparent when you set up the groups. I think I was just a bit doubtful of having Tree and Group in the name at the same time, since they both describe some aspect of data structure. But they're both relevant, so I guess that's OK. If there were an Authz:: namespace, I'd probably go for Authz::Tree, so maybe I should go for Tree::Authz. By the way, I'd argue that there probably _should_ be an Authz:: namespace, just as there is an Authen:: namespace. They're different things. Although some of the Authen:: modules support authorization, it also makes sense that authorization can be abstracted out from authentication. This is more difficult than writing the damn thing! d. -- david nicol Someday, everything's going to be different when I paint my masterpiece. -- Dr. David R. Baird Riverside Content Management Systems [EMAIL PROTECTED] http://www.riverside-cms.co.uk
Re: namespace for users and groups
On 21 Aug 2004 at 18:18, david nicol wrote:
On Sat, 2004-08-21 at 16:00, Kurt Starsinic wrote:
Also, when you're talking about groups of groups as above, the
more common term of art is accounts and subaccounts.
- Kurt
While we're pitching terms, *nix, which unashamedly uses groups
for these things, talks about permissions or perms while
the access control list school of thought talks about the ACL.
Yes, I'm a bit stuck in the Unix terminology, I need to do a bit more
research around ACL in particular. At first glance, a lot of the ACL
modules are implementing protocols to communicate with various
authentication services. But something like Data::ACL covers a lot of
the ground I'm thinking about. Mine adds the ability to associate
code with the groups in the ACL, and uses a different mechanism for
setting up the groups hierarchy. Maybe I should call it something
like Tree::ACL::MethodMaker.
Permissions, privileges, capabilities are generally handled by
the environment in which a program is operating, which leads me
to the suspicion that you're operating in a CGI context. Assuming
you're using something else for the authentication phase, and
since accounting was not mentioned in your query, I'll propose
CGI::Perms::Baird
as something to work from. Boldly brand!
Hmm. Much as I like the suggestion, I don't think it communicates
much about what the module is doing!
Sure, many programs operate in an environment that already
provides/enforces a particular authentication mechanism. If so, my
module isn't for you, it's not an interface to an authentication or
authorization service. It provides an authorization service. Yes, I'm
building web apps, but I don't see that the permissions management
subsystem has anything to do with that environment. I happen to
receive usernames and passwords from form submissions, but that's
irrelevant to this module.
At the moment, I'm favouring something with Tree and ACL in it, plus
something like MethodMaker to indicate the code-managing aspect.
Maybe Perms instead of ACL, but ACL seems to be the standard
terminology.
The API would look something like
my $groups = ... get a tree structure ...
# just like Data::ACL
my $acl = Tree::ACL::MethodMaker-new( $groups );
# add some capabilities
# this one is just like Data::ACL -
$acl-group( 'groupname' )-add_permission( 'admin' );
# these are new stuff -
$acl-group( 'groupname' )-add_abilities( edit = $coderef );
$acl-group( 'groupname' )-add_abilities( 'Some::Package' );
# not part of my module:
my $user = authenticate_and_return_user( $username, $password );
# this one is just like Data::ACL -
if ( $user-get_group-is_allowed( 'admin' ) {
# do admin stuff
}
# these are new stuff -
if ( $user-get_group-can_do( 'edit' ) ) {
$user-get_group-edit( @args );
}
if ( $user-get_group-can_do( 'create_user' ) {
# Some::Package::create_user
$user-get_group-create_user( @other_args );
}
You could easily define pass-through methods in your user class so
you can call these methods directly on the user.
Cheers,
d.
--
Dr. David R. Baird
Riverside Content Management Systems
[EMAIL PROTECTED]
http://www.riverside-cms.co.uk
Re: namespace for users and groups
On 22 Aug 2004 at 17:26, david nicol wrote: On Sun, 2004-08-22 at 08:22, David R. Baird wrote: At the moment, I'm favouring something with Tree and ACL in it, plus something like MethodMaker to indicate the code-managing aspect. Maybe Perms instead of ACL, but ACL seems to be the standard terminology. ACL and groups are different competing way of skinning the same cat. in groups, you associate the capability with the group and list the users with the capability in the group. with access control lists, every protected resource keeps a list of users and privelege levels. OK, that's very useful, so I'm building groups rather than ACLs. Systems such as TACACS and RADIUS have whole languages for creating processes that can answer authorization questions. For that matter, so are firewall rules, .htaccess files, and any section of any configuration file containing the words allow or deny. I'll have a look at these and bring my terminology into line. Moving towards something like Tree::Authz::Group. I'm not 100% sure of the Tree:: bit (although it is based on a tree structure), but I can't see where else it could fit in. d. -- Dr. David R. Baird Riverside Content Management Systems [EMAIL PROTECTED] http://www.riverside-cms.co.uk
