slashcode-development — This list is for development of slashcode, no install questions please.

Re: [Slashcode-development] ACLs for slashcode

[Chris N. <pu...@po...>]

At 18:02 +0100 2001.03.12, Alvaro del Castillo wrote:
>Hi!
>
>> Yeah, I was thinking about something very similar at one point, and think
>> this is a nice idea.  I wonder, though, if maybe users_param would be a
>> better user of this?  So instead of:
>>
>> >mysql> select op_insert_index from users_acl where uid=45;
>>
>> You would have:
>>
>>   select value from users_param where uid = 45 and name = 'op_insert_index';
>
>Yes, i have looked to this table and it is perfect for the use we are
>doing
>of users_acl. But the name and value fields must be bigger. A user can
>have
>lots of sections in wich it can do some operations. I don't know if
>when you designed the table you have in mind params so large.

Actually, users_param just uses a text field for "value" now.  So the only
issue would be picking a better limit for "name".


At 18:09 +0100 2001.03.12, Alvaro del Castillo wrote:
>Do you think that this model could replace the seclev model in
>the future? As I say in other email, I have found very easy to make
>co-live the to models in the transition.

I think so, yes, though there could be something i am not thinking of.
Currently we only use seclev for "is anonymous," "is regular user," "is
author," "is admin."  But this would be replaced by things like
"can_unlimited_moderate" etc. in the ACLs.

-- 
Chris Nandor                      pu...@po...    http://pudge.net/
Open Source Development Network    pu...@os...     http://osdn.com/

Re: [Slashcode-development] ACLs for slashcode

[Brian A. <br...@ta...>]

Alvaro del Castillo wrote:
> If we use the users_param table we don't need to touch getUser and
> setUser,
> no?
True, you could. The only thing that would be left is a table describing
the ACL.
The only thing I worry about is that users_param is a type of text,
which could be slow for very large sites. Which is why you might want
to have a separate table. Course, the table is entirely indexed.
Just put it in users_param, if it turns out to be a performance
issue it will be easy to fix.

> The changes are reduced to modify the ACL functions that I have included
> in Slash.pm. Is it the correct place? This changes are minimal.
Well, the ACL functions should be in Slash::Utility. 

> the future? As I say in other email, I have found very easy to make
> co-live the to models in the transition.
We can make the two live side by site at the moment. Long term
I would prefer to see only one though (just me), but I don't
see it as a priority.

> I plan to send a patch to the list to show how we have modified admin.pl
> to partially work using ACLs.
Cool.

	-Brian

Re: [Slashcode-development] ACLs for slashcode

[Alvaro d. C. <ac...@ba...>]

Brian Aker wrote:
> 
> Chris Nandor wrote:
> > Yeah, I was thinking about something very similar at one point, and think
> > this is a nice idea.  I wonder, though, if maybe users_param would be a
> > better user of this?  So instead of:
> I would keep it out of users_param, but use the same schema.
> 
> > Or, alternatively, implement users_acl _as_ a param-style table.  The
> > problem, of course, is that we could have dozens of types of permissions,
> > and it is easier to just insert a new value than it is to change the schema
> > each time you want to add a new one (and this would make it more easily
> > extensible via the admin interface, too).  Also, a table with a few dozen
> > fields could be slower and more bloated.
> The param style table is actually pretty quick for look ups.
> 
> If the schema was modified to resemble a param table and we had patches
> for getUser() and setUser() I would probably be all for including it.

If we use the users_param table we don't need to touch getUser and
setUser,
no?

The changes are reduced to modify the ACL functions that I have included
in Slash.pm. Is it the correct place? This changes are minimal.

> 
> It might be nice also to have a seperate table which described param's
> currently in use.

Yes, because the kind of operations that a site can have can't be
determinated
a priori. The ACL scheme enables the creations of new operations
without any need to change the actual code. Only when you have to
take advantge of this new operations you have to tell it to the
getACLindex.

Do you think that this model could replace the seclev model in
the future? As I say in other email, I have found very easy to make
co-live the to models in the transition.

I plan to send a patch to the list to show how we have modified admin.pl
to partially work using ACLs.

Bye

-- Alvaro

>         -Brian
> 
> _______________________________________________
> Slashcode-development mailing list
> Sla...@li...
> http://lists.sourceforge.net/lists/listinfo/slashcode-development

-- 
===================================================
Alvaro del Castillo San Félix	ac...@ba...
Barrapunto.com

Re: [Slashcode-development] ACLs for slashcode

[Alvaro d. C. <ac...@ba...>]

Hi!

> Yeah, I was thinking about something very similar at one point, and think
> this is a nice idea.  I wonder, though, if maybe users_param would be a
> better user of this?  So instead of:
> 
> >mysql> select op_insert_index from users_acl where uid=45;
> 
> You would have:
> 
>   select value from users_param where uid = 45 and name = 'op_insert_index';

Yes, i have looked to this table and it is perfect for the use we are
doing
of users_acl. But the name and value fields must be bigger. A user can
have
lots of sections in wich it can do some operations. I don't know if
when you designed the table you have in mind params so large.

> 
> Or, alternatively, implement users_acl _as_ a param-style table.  The
> problem, of course, is that we could have dozens of types of permissions,
> and it is easier to just insert a new value than it is to change the schema
> each time you want to add a new one (and this would make it more easily
> extensible via the admin interface, too).  Also, a table with a few dozen
> fields could be slower and more bloated.

Yes, thinking in the users_param table it is more flexible than the
actual
users_acl which needs to be altered each time a new permissions is
created. With the users_param table the things are more flexible and as
you say, it makes more easy to create new type of permisssions from
the admin interface.

At the moment we use the ACLs to control only sections. We create a new 
section and then, we give ACL op_admin_index to some users. This users
then can give the ACLs op_admin_index, op_insert_index or
op_delete_index
to other users. This "admin" users have the control over the index and
they
can work on in an independent way from the main editors.

Other example is when a user creates her MySlash, it is created
automatically
a new section for her stories and the user receives the op_admin_index
ACL
over her new section. Then, the user can works in the section and can
give ACLs for other users. ACLs enable a very decentralized way of work
so you can give more power to the community.

Bye

-- Alvaro
> 
> --
> Chris Nandor                      pu...@po...    http://pudge.net/
> Open Source Development Network    pu...@os...     http://osdn.com/
> 
> _______________________________________________
> Slashcode-development mailing list
> Sla...@li...
> http://lists.sourceforge.net/lists/listinfo/slashcode-development

-- 
===================================================
Alvaro del Castillo San Félix	ac...@ba...
Barrapunto.com

Re: [Slashcode-development] ACLs for slashcode

[Chris N. <pu...@po...>]

At 09:47 -0800 2001.03.12, Brian Aker wrote:
>Chris Nandor wrote:
>> Yeah, I was thinking about something very similar at one point, and think
>> this is a nice idea.  I wonder, though, if maybe users_param would be a
>> better user of this?  So instead of:

>I would keep it out of users_param, but use the same schema.

>> Or, alternatively, implement users_acl _as_ a param-style table.  The

Yeah, I think that would be best.

-- 
Chris Nandor                      pu...@po...    http://pudge.net/
Open Source Development Network    pu...@os...     http://osdn.com/

Re: [Slashcode-development] ACLs for slashcode

[Brian A. <br...@ta...>]

Chris Nandor wrote:
> Yeah, I was thinking about something very similar at one point, and think
> this is a nice idea.  I wonder, though, if maybe users_param would be a
> better user of this?  So instead of:
I would keep it out of users_param, but use the same schema. 

> Or, alternatively, implement users_acl _as_ a param-style table.  The
> problem, of course, is that we could have dozens of types of permissions,
> and it is easier to just insert a new value than it is to change the schema
> each time you want to add a new one (and this would make it more easily
> extensible via the admin interface, too).  Also, a table with a few dozen
> fields could be slower and more bloated.
The param style table is actually pretty quick for look ups. 

If the schema was modified to resemble a param table and we had patches
for getUser() and setUser() I would probably be all for including it.

It might be nice also to have a seperate table which described param's
currently in use.
	-Brian

Re: [Slashcode-development] ACLs for slashcode

[Chris N. <pu...@po...>]

At 08:26 +0100 2001.03.10, Alvaro del Castillo wrote:
>mysql> desc users_acl;
>+-----------------+---------+------+-----+---------+-------+
>| Field           | Type    | Null | Key | Default | Extra |
>+-----------------+---------+------+-----+---------+-------+
>| uid             | int(11) |      | PRI | 0       |       |
>| op_insert_index | text    | YES  |     | NULL    |       |
>| op_delete_index | text    | YES  |     | NULL    |       |
>| op_admin_index  | text    | YES  |     | NULL    |       |
>+-----------------+---------+------+-----+---------+-------+
>
>
>At the moment we only need to control this three operations, but the
>scheme can be expanded easily.
>
>When a user reach the site, in the users object we also put the ACLs. So
>in $user->{op_insert_index} appear all the sections in which the user
>can
>insert stories. An so on with the other operations.

Yeah, I was thinking about something very similar at one point, and think
this is a nice idea.  I wonder, though, if maybe users_param would be a
better user of this?  So instead of:

>mysql> select op_insert_index from users_acl where uid=45;

You would have:

  select value from users_param where uid = 45 and name = 'op_insert_index';

Or, alternatively, implement users_acl _as_ a param-style table.  The
problem, of course, is that we could have dozens of types of permissions,
and it is easier to just insert a new value than it is to change the schema
each time you want to add a new one (and this would make it more easily
extensible via the admin interface, too).  Also, a table with a few dozen
fields could be slower and more bloated.

-- 
Chris Nandor                      pu...@po...    http://pudge.net/
Open Source Development Network    pu...@os...     http://osdn.com/

[Slashcode-development] Details about a possible ACL implementation

[Alvaro d. C. <ac...@ba...>]

Hi!

I attach to this email some patch to slashcode-1.1.5 to show how
we have implemented the ACL scheme for slashcode. This patches aren't
for be used for now. Only for information purpouses.

Also this patches show the simple way in which the same story could be
in several
sections. This little change enables several great things like
automatic indexes: you build indexes using some detail like
keywords, themes, sections, comments scores, number of visit/comments
for a story ... so you can have several new sections using the same
stories
but with different criteriums.

* barrapunto.sql: the new tables needed
* users.pl.diff: some changes that enables a user to active her MySlash
* Slash.diff: the ACL functions
* MySQL.pm.diff: changes to support ACLs and indexes
* editHome;user;default.diff: changes that works with users.pl.diff

Cheers

-- Alvaro
===================================================
Alvaro del Castillo San Félix	ac...@ba...
Barrapunto.com

[Slashcode-development] ACLs for slashcode

[Alvaro d. C. <ac...@ba...>]

Brian Aker wrote:
> 
> Alvaro del Castillo wrote:
> > Our main success has been to introduce an ACL scheme in Bender. We need
> > it because we have modified the software so each registered user can
> > have its own section and we have to give it the admin interface in a
> > controled way.
> Can you expllain how your ACL's work?


It's very simple:

We have created a new table users_acl

mysql> desc users_acl;
+-----------------+---------+------+-----+---------+-------+
| Field           | Type    | Null | Key | Default | Extra |
+-----------------+---------+------+-----+---------+-------+
| uid             | int(11) |      | PRI | 0       |       |
| op_insert_index | text    | YES  |     | NULL    |       |
| op_delete_index | text    | YES  |     | NULL    |       |
| op_admin_index  | text    | YES  |     | NULL    |       |
+-----------------+---------+------+-----+---------+-------+


At the moment we only need to control this three operations, but the
scheme can be expanded easily.

When a user reach the site, in the users object we also put the ACLs. So
in $user->{op_insert_index} appear all the sections in which the user
can
insert stories. An so on with the other operations.

For example:

mysql> select op_insert_index from users_acl where uid=45;
+--------------------------------------------------------------------------------------------------------------------------------+
|
op_insert_index                                                                                                               
|
+--------------------------------------------------------------------------------------------------------------------------------+
|
'mbp-acs','index','kde','gnome','mbp-rodrigo','solo-es','solo-mx','mbp-esteve','empresas','boinapunto','mbp-giordino','debian'
|
+--------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

If we want to create a new ACL that control if a user can insert polls
in
a section, it's easy. We modify the table and add a new column with the
new
operation.

The functions that controls if a user has a correct ACL are independant 
of the number of operations that appear in that table.

This functions are:

getACLindex ($op,$index)
removeACLindex($uid,$op,$op_indexes) (it works for several indexes)
saveACLindex($uid,$op,$op_indexes) (it works for several indexes)

The getACLindex don't touch the database because all the information
that it needs is the $user object.

For example, if you want to let the user use admin.pl in a ACL way:

admin.pl (1.09):

...

if (($op eq 'edit')&&(getACLindex("op_insert_index","*"))) {
                        editstory($I{F}{sid});

With $index value equal "*" getACLindex returns true if the user can
insert
stories in some index.

In our site we have the two schemes, ACLs and seclev, working together
but
we plan to migrate everything to the ACLs scheme. The migration from 
one scheme to the other is not difficult and can be done smoothly.

At the moment, with users_acl we only can control using the section
concept
but it could be easy to expand the model.

The key is that this scheme is integrated with slashcode in a clean way.
We have migrated to bender very easy. Only we have to modify Slash::DB
to
tell getUser and setUser to take the data also from users_acl.

In our site we have developed this idea and we have the concept of 
MySlash. An user can has it own "mini-slash site" integrated with 
the site. For this we have to make another key change in slashcode
architecture: an story can appear the same in more than one section.
This little change, a new table that relation stories and sections, 
has enabled us to build a great stories syndication platform.

I hope I have explain everything clear but maybe, the patch will show
you
the details. It could be great to integrate our work with the main
slashcode root.

Cheers

-- Alvaro



> 
> > Also, I am writing a doc about Bender architeture. Some Dia diagrams and
> > some text describing the architectura. Is there any doc yet about Bender
> > architetcure?
> I am working on such a beast and one should exist by monday.
>         -Brian
> --
> _______________________________________________________
> Brian Aker, br...@ta...
> Slashdot Senior Developer
> Seattle, Washington
> http://tangent.org/~brian/
> http://slashdot.org/
> _______________________________________________________
> You can't grep a dead tree.
> 
> _______________________________________________
> Slashcode-development mailing list
> Sla...@li...
> http://lists.sourceforge.net/lists/listinfo/slashcode-development

-- 
===================================================
Alvaro del Castillo San Félix	ac...@ba...
Barrapunto.com

Re: [Slashcode-development] Presentation

[Brian A. <br...@ta...>]

Alvaro del Castillo wrote:
> Our main success has been to introduce an ACL scheme in Bender. We need
> it because we have modified the software so each registered user can
> have its own section and we have to give it the admin interface in a
> controled way.
Can you expllain how your ACL's work?

> Also, I am writing a doc about Bender architeture. Some Dia diagrams and
> some text describing the architectura. Is there any doc yet about Bender
> architetcure?
I am working on such a beast and one should exist by monday.
	-Brian
-- 
_______________________________________________________
Brian Aker, br...@ta... 
Slashdot Senior Developer
Seattle, Washington
http://tangent.org/~brian/
http://slashdot.org/
_______________________________________________________
You can't grep a dead tree.

[Slashcode-development] Presentation

[Alvaro d. C. <ac...@ba...>]

Hi!

Yesterday I found that a list about slashcode development exists.
¡Great!

My name is Alvaro del Castillo and I work for BarraPunto.com a 
Spanish weblog about free software and many other things ;-) Yes,
it is based in slashcode ;-)

I have worked in slashcode for the last 4 months and I think I know
it in some depth. As many of other users of slashcode we have modified
it in several ways and now we are migrating all our new code to Bender.

Bender is a great advance. It has a solid architecture. After some time
exploring it, we have migrated our new code to Bender without breaking
the clean architecture scheme.

Our main success has been to introduce an ACL scheme in Bender. We need
it because we have modified the software so each registered user can
have its own section and we have to give it the admin interface in a 
controled way.

I think that our ACL scheme could be a great tool for slashcode and 
I hope to send you a patch so you can check it. I have worked in
1.1.4 so when I download 1.1.5 and migrates the changes, I will send
the patch.

Also, I am writing a doc about Bender architeture. Some Dia diagrams and
some text describing the architectura. Is there any doc yet about Bender
architetcure?

Greetings and happy hacking

-- Alvaro
===================================================
Alvaro del Castillo San Félix	ac...@ba...
Barrapunto.com

[Slashcode-development] Upgrading to the latest journal

[Brian A. <br...@ta...>]

So, if you have already started using bender on a production site and 
have been updating from CVS you will notice that the schema has
changed. The following will update your schema so that you 
don't loose all of your data:

create table journals_text SELECT id,article from journals;
alter table journals drop article;
alter table journals_text add primary key (id);


Have fun.
	-Brian

[Slashcode-development] Index mode

[CertIndex.com W. <web...@ce...>]

I've played around on slashdot for a while now trying to figure out exactly
what 'Index mode' for comments does, but I can't figure it out. Would anyone
mind sharing with me what 'spilling into index mode' means and what 'index
mode' does? thanks a lot

[Slashcode-development] documentation

[CertIndex.com W. <web...@ce...>]

just to let you guys know, several columns in the users_info table are not
documented in
ftp://ftp.snap-shot.org/pub/slash/Slash_Database_Description.html

considering this, i must ask what the column session_login does and is for.
thanks!

regards

[Slashcode-development] redundant data?

[CertIndex.com W. <web...@ce...>]

from reading the table desc. at
ftp://ftp.snap-shot.org/pub/slash/Slash_Database_Description.html it seems
the following 2 tables have columns for the same info:

users_comments / points - int(11) - number of moderation points user
currently has

users_info / tokens - int(11) - moderating tokens currently granted to user


i'm probably wrong so please tell me where. sorry but these descriptions
aren't very descriptive.

Re: [Slashcode-development] Slash under load

[Brian A. <br...@ta...>]

T F wrote:
> Does slashcode use the same mega-mysql server that slashdot uses?
Nope, neither the old one nor the new one (and the old server
has several sites on it). When we are done with the latest
imports I can give a run down on the size of our DB. The machine
is a dual processor with 1 gig of RAM. Overkill to be honest.

I have one site that is running with bender at the moment
(combination between multiple systems though). It has a half
gig of memory and 2 200MHZ  pentium pros in it. It runs several
sites and has the DB running on it. Its performance with 5K of
page views a day is fine.

I can tell you though that my Sparc Classic with 72 megs of RAM
will technically run bender, but the pages take 6 seconds to 
send. Think low end pentium if you want to compare it to 
an intel box. It really is to slow. I have not tried loading
it on my one Pentium 120 in the house.

	-Brian

Re: [Slashcode-development] Slash under load

[T F <tf...@ho...>]

>From: Brian Aker <br...@ta...>
>elijah wright wrote:
> > hmm i would assume that slashdot (even though they're not running bender
> > yet, as i hear?) gets more hits than that... am i wrong?
>Quite a bit more. Slashcode will be moved to bender within the next
>couple of days so we will be able to see how it handles it
>(it peaks around 7K page views a day). When we also have use.perl.org
>on the box we will have a better idea.
>	-Brian

Does slashcode use the same mega-mysql server that slashdot uses?


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [Slashcode-development] Slash under load

[Brian A. <br...@ta...>]

elijah wright wrote:
> hmm i would assume that slashdot (even though they're not running bender
> yet, as i hear?) gets more hits than that... am i wrong?
Quite a bit more. Slashcode will be moved to bender within the next
couple of days so we will be able to see how it handles it
(it peaks around 7K page views a day). When we also have use.perl.org
on the box we will have a better idea.
	-Brian

Re: [Slashcode-development] Slash under load

[elijah w. <el...@st...>]

> >I'm curious if anyone here runs a site that gets more than 10k page views /
> >day running Bender. If you do, how's it fairing?
> If anyone is (and I doubt anyone's running in production yet, but I could be 
> wrong) I wouldn't mind knowing what kind of hardware they have backing it 
> up.

hmm i would assume that slashdot (even though they're not running bender
yet, as i hear?) gets more hits than that... am i wrong?

elijah

Re: [Slashcode-development] Slash under load

[T F <tf...@ho...>]

>I'm curious if anyone here runs a site that gets more than 10k page views /
>day running Bender. If you do, how's it fairing?
>
>Regards

If anyone is (and I doubt anyone's running in production yet, but I could be 
wrong) I wouldn't mind knowing what kind of hardware they have backing it 
up.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

[Slashcode-development] Slash under load

[CertIndex.com W. <web...@ce...>]

I'm curious if anyone here runs a site that gets more than 10k page views /
day running Bender. If you do, how's it fairing?

Regards

Re: [Slashcode-development] Apache::Cookie

[Chris N. <pu...@po...>]

At 16:55 -0800 2001.02.27, Brian Aker wrote:
>Chris Nandor wrote:
>> Brian, where was CGI being used before?

>Somehow it was being included in CGI::Cookie (didn't you write
>something about how you found it?).

Yes.  But I upgraded CGI::Cookie, and so it no longer used CGI.  And I note
that now, I look in perl-status, and CGI::Cookie and CGI::Util are still
there.  But CGI is not.


>> Also, should Apache::CGI be in Bundle::Slash (I assume "yes")?  Will it
>> hurt any site that does not use it (like 1.0.x sites)?
>It won't hurt anything; it would be safe to add it to Bundle::Slash.

OK.

-- 
Chris Nandor                      pu...@po...    http://pudge.net/
Open Source Development Network    pu...@os...     http://osdn.com/

Re: [Slashcode-development] Apache::Cookie

[Patrick G. <cap...@sl...>]

Chris Nandor wrote:
> 
> At 16:11 -0800 2001.02.27, Brian Aker wrote:
> >Good news! The problem with debian and CGI has been fixed.
> >We are no longer using CGI :)
> >
> >Bad news, if you are installing from cvs, you need to
> >add Apache::CGI from CPAN to your perl setup.
> 
> Brian, where was CGI being used before?
> 
> Also, should Apache::CGI be in Bundle::Slash (I assume "yes")?  Will it
> hurt any site that does not use it (like 1.0.x sites)?
> 
> --
> Chris Nandor                      pu...@po...    http://pudge.net/
> Open Source Development Network    pu...@os...     http://osdn.com/
> 
> _______________________________________________
> Slashcode-development mailing list
> Sla...@li...
> http://lists.sourceforge.net/lists/listinfo/slashcode-development

yes, I second that question :)

Re: [Slashcode-development] Apache::Cookie

[Brian A. <br...@ta...>]

Chris Nandor wrote:
> Brian, where was CGI being used before?
Somehow it was being included in CGI::Cookie (didn't you write
something about how you found it?).

> Also, should Apache::CGI be in Bundle::Slash (I assume "yes")?  Will it
> hurt any site that does not use it (like 1.0.x sites)?
It won't hurt anything; it would be safe to add it to Bundle::Slash.

	-Brian

Re: [Slashcode-development] Apache::Cookie

[Chris N. <pu...@po...>]

At 16:11 -0800 2001.02.27, Brian Aker wrote:
>Good news! The problem with debian and CGI has been fixed.
>We are no longer using CGI :)
>
>Bad news, if you are installing from cvs, you need to
>add Apache::CGI from CPAN to your perl setup.

Brian, where was CGI being used before?

Also, should Apache::CGI be in Bundle::Slash (I assume "yes")?  Will it
hurt any site that does not use it (like 1.0.x sites)?

-- 
Chris Nandor                      pu...@po...    http://pudge.net/
Open Source Development Network    pu...@os...     http://osdn.com/