[geeklog-devtalk] geeklog-devel digest, Vol 1 #349 - 13 msgs

geeklog-devel-request at lists.geeklog.net geeklog-devel-request at lists.geeklog.net
Mon Jul 12 17:42:01 EDT 2004

Send geeklog-devel mailing list submissions to
geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

1. Re: Spam Plugin (Dirk Haun)
2. Re: Spam Plugin (Tony Bibbs)
3. GL2 Article Plugin. Speak now or forever hold your peace (Tony Bibbs)
4. Brainstorming: Admin Toolbox? (Dirk Haun)
5. Re: Brainstorming: Admin Toolbox? (Tony Bibbs)
6. Re: Brainstorming: Admin Toolbox? (Dirk Haun)
7. Re: Brainstorming: Admin Toolbox? (Tom Willett)
8. Re: Brainstorming: Admin Toolbox? (Tom Willett)
9. Re: Brainstorming: Admin Toolbox? (Dirk Haun)
10. Brainstorming -- Spam Comment API (Tom Willett)
11. Re: Brainstorming: Admin Toolbox? (Tom Willett)
12. Re: Brainstorming: Admin Toolbox? (Tony Bibbs)
13. Re: Brainstorming: Admin Toolbox? (Tony Bibbs)

--__--__--

Message: 1
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Spam Plugin
Date: Mon, 12 Jul 2004 20:02:09 +0200
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Tony,


>Aren't we just delaying the inevitable. All indications are this will

>get worse before it gets better.


I'm with you on this one. When it comes to spam, it can't hurt to prepare
for the worst-case scenario.



>Dirk, your thoughts? I you are still agreeable, I may take a swag at

>integrating it into the default GL installation.


My only gripe with the SpamX plugin is that it requires additional files
to be writable. If you can solve that one, then by all means integrate it.

bye, Dirk


--
http://www.haun-online.de/
http://geeklog.info/


--__--__--

Message: 2
Date: Mon, 12 Jul 2004 13:22:15 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Spam Plugin
Reply-To: geeklog-devel at lists.geeklog.net

Funny thing is I havne't even used it. I've looked into the blacklist
used and was generally impressed so I will work with Tom to see if we
can't get rid of the file-write dependency.

Tom, if you get any time, jump into IRC and we can chat.

--Tony

Dirk Haun wrote:


>Tony,

>

>

>

>>Aren't we just delaying the inevitable. All indications are this will

>>get worse before it gets better.

>>

>>

>

>I'm with you on this one. When it comes to spam, it can't hurt to prepare

>for the worst-case scenario.

>

>

>

>

>>Dirk, your thoughts? I you are still agreeable, I may take a swag at

>>integrating it into the default GL installation.

>>

>>

>

>My only gripe with the SpamX plugin is that it requires additional files

>to be writable. If you can solve that one, then by all means integrate it.

>

>bye, Dirk

>

>

>

>


--__--__--

Message: 3
Date: Mon, 12 Jul 2004 13:37:24 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] GL2 Article Plugin. Speak now or forever hold your peace
Reply-To: geeklog-devel at lists.geeklog.net

FYI, I have posted a request for feature on the GL2 article plugin.

Go here to participate:

http://www.geeklog.net/article.php?story=20040712142246310

--Tony

--__--__--

Message: 4
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Date: Mon, 12 Jul 2004 21:48:33 +0200
Organization: Terra Software Systems
Subject: [geeklog-devel] Brainstorming: Admin Toolbox?
Reply-To: geeklog-devel at lists.geeklog.net

Gentlemen,

I see a need for a set of scripts to do maintenance tasks and such (for
example, I just wrote a tiny script that does an OPTIMIZE TABLE on all
the tables). It would be nice if there was a simple way to plug these
sorts of scripts into Geeklog without having to make them full-blown plugins.

Ideally, I would like to be able to just drop my script into some
predefined location and have Geeklog pick it up automatically. An admin-
only plugin "lite", so to speak.

I could imagine a link, say, "Site Maintenance" or "Admin Toolbox" (Hi
Tom), in the Admin block, which then presents a list of all the availble
mini-plugins (with a short description?).

I'd like this to be
- easy to install (one file per mini-plugin, one location)
- admin only
- the "wrapper" script could do the actual permission checks, so they
don't have to be coded again in each file

Any good ideas for an API, anyone?

bye, Dirk

P.S. As for the "Admin Toolbox" name: I think Tom's collection of scripts
under that name would also fit nicely into this.


--
http://www.haun-online.de/
http://mypod.de/


--__--__--

Message: 5
Date: Mon, 12 Jul 2004 15:40:50 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?
Reply-To: geeklog-devel at lists.geeklog.net


Dirk Haun wrote:


>Gentlemen,

>

>I see a need for a set of scripts to do maintenance tasks and such (for

>example, I just wrote a tiny script that does an OPTIMIZE TABLE on all

>the tables). It would be nice if there was a simple way to plug these

>sorts of scripts into Geeklog without having to make them full-blown plugins.

>

>Ideally, I would like to be able to just drop my script into some

>predefined location and have Geeklog pick it up automatically. An admin-

>only plugin "lite", so to speak.

>

>I could imagine a link, say, "Site Maintenance" or "Admin Toolbox" (Hi

>Tom), in the Admin block, which then presents a list of all the availble

>mini-plugins (with a short description?).

>

>

K, I think an simple interface should be implemented. Also, I'm a bit
partial to an OO-design so how is this as a stubbed out class:

<?php

class GeeklogScriptlet {
var $_author = null;
var $_shortDesc = null;
var $_longDesc = null;
var $_version = null;

function userCanRunScript()
{
if (!SEC_inGroup('Root')) {
return false;
}
return true;
}

function GeeklogScriptlet()
{
$_author = 'John or Jane Doe';
$_shortDesc = 'Short Description goes here';
$_longDesc = 'Long Description goes here';
}

function getAuthor()
{
return $this->_author;
}

function getShortDesc()
{
return $this->_shortDesc;
}

function getLongDesc()
{
return $this->_longDesc;
}

function getVersion()
{
return $this-_version;
}

function runScript()
{
// All the work of the script goes here.
}
}

?>


>I'd like this to be

>- easy to install (one file per mini-plugin, one location)

>

>

Using the class above, you could put all scripts in one directory
outside the webtree or in a database. Then you would create an main
admin page e.g. /admin/runScriptlet.php?name=GeeklogScriptlet.
Naturally the class above is meant to be abstract so people would
inherit from it and change as needed. This
will allow the security to be done once, etc.

My vote would be to put the contents of the script in a database to
avoid permission issues on the files. Plus by doing this we do advanced
security checks. For example, given this sort of stuff can potentially
do harm, we should notice if this is the first time the script has been
called and ask if they are sure they want to enable the script. We
should also give them a chance to review the code at that time.

--Tony

--__--__--

Message: 6
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?
Date: Mon, 12 Jul 2004 22:58:29 +0200
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Tony,


>K, I think an simple interface should be implemented. Also, I'm a bit

>partial to an OO-design so how is this as a stubbed out class:


No problem with OO - I've actually expected this to be implemented as a class.



>class GeeklogScriptlet {


First impression is good.



> function runScript()

> {

> // All the work of the script goes here.

> }


Not sure about this one, but do we want to support more than one function
per scriptlet? Or would those go into separate scriptlets?

Also, what about POST requests? How do they come back into the scriptlet?



>Using the class above, you could put all scripts in one directory

>outside the webtree or in a database.


Outside of the webtree makes sense. Not sure about the database, as it
also beats the "simple installation" idea.



>My vote would be to put the contents of the script in a database to

>avoid permission issues on the files.


I don't really see any file permission issues. The scriptlets are
probably included(?) or they're simple .php files.

Anyway, not bad for a first draft.

bye, Dirk


--
http://www.haun-online.de/
http://mypod.de/


--__--__--

Message: 7
From: "Tom Willett" <tomw at pigstye.net>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?
Date: Mon, 12 Jul 2004 21:18:28 +0000
Reply-To: geeklog-devel at lists.geeklog.net

Looks good to me.

My vote would be to just place the scripts in a specific location.

The only suggestion that I would make is to make the permissions more
flexible. That way if root delegated authority to someone, they too could
access the script. Of course this would require either some sort of
database table to manage the permissions or editing of the script file to
add them. The latter is the easiest way.

--
Tom Willett
tomw at pigstye.net

---------- Original Message -----------
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Sent: Mon, 12 Jul 2004 15:40:50 -0500
Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?


> Dirk Haun wrote:

>

> >Gentlemen,

> >

> >I see a need for a set of scripts to do maintenance tasks and such (for

> >example, I just wrote a tiny script that does an OPTIMIZE TABLE on all

> >the tables). It would be nice if there was a simple way to plug these

> >sorts of scripts into Geeklog without having to make them full-blown

plugins.

> >

> >Ideally, I would like to be able to just drop my script into some

> >predefined location and have Geeklog pick it up automatically. An admin-

> >only plugin "lite", so to speak.

> >

> >I could imagine a link, say, "Site Maintenance" or "Admin Toolbox" (Hi

> >Tom), in the Admin block, which then presents a list of all the availble

> >mini-plugins (with a short description?).

> >

> >

> K, I think an simple interface should be implemented. Also, I'm a bit

> partial to an OO-design so how is this as a stubbed out class:

>

> <?php

>

> class GeeklogScriptlet {

> var $_author = null;

> var $_shortDesc = null;

> var $_longDesc = null;

> var $_version = null;

>

> function userCanRunScript()

> {

> if (!SEC_inGroup('Root')) {

> return false;

> }

> return true;

> }

>

> function GeeklogScriptlet()

> {

> $_author = 'John or Jane Doe';

> $_shortDesc = 'Short Description goes here';

> $_longDesc = 'Long Description goes here';

> }

>

> function getAuthor()

> {

> return $this->_author;

> }

>

> function getShortDesc()

> {

> return $this->_shortDesc;

> }

>

> function getLongDesc()

> {

> return $this->_longDesc;

> }

>

> function getVersion()

> {

> return $this-_version;

> }

>

> function runScript()

> {

> // All the work of the script goes here.

> }

> }

>

> ?>

>

> >I'd like this to be

> >- easy to install (one file per mini-plugin, one location)

> >

> >

> Using the class above, you could put all scripts in one directory

> outside the webtree or in a database. Then you would create an main

> admin page e.g. /admin/runScriptlet.php?name=GeeklogScriptlet.

> Naturally the class above is meant to be abstract so people would

> inherit from it and change as needed. This

> will allow the security to be done once, etc.

>

> My vote would be to put the contents of the script in a database to

> avoid permission issues on the files. Plus by doing this we do advanced

> security checks. For example, given this sort of stuff can potentially

> do harm, we should notice if this is the first time the script has been

> called and ask if they are sure they want to enable the script. We

> should also give them a chance to review the code at that time.

>

> --Tony

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

------- End of Original Message -------


--__--__--

Message: 8
From: "Tom Willett" <tomw at pigstye.net>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?
Date: Mon, 12 Jul 2004 21:22:24 +0000
Reply-To: geeklog-devel at lists.geeklog.net

Dirk,


> Not sure about this one, but do we want to support more than one function

> per scriptlet? Or would those go into separate scriptlets?

>

> Also, what about POST requests? How do they come back into the scriptlet?

>


No problem with either of these issues -- you can have single or multiple
scripts in a class -- this is how the spamx plugin is implemented if you
would like to see an example.

TomW

--__--__--

Message: 9
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?
Date: Mon, 12 Jul 2004 23:17:08 +0200
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Tom,


>The only suggestion that I would make is to make the permissions more

>flexible. That way if root delegated authority to someone, they too could

>access the script.


I think this function already handles this nicely:


>> function userCanRunScript()

>> {

>> if (!SEC_inGroup('Root')) {

>> return false;

>> }

>> return true;

>> }


The scriptlet could implement any authentication it wants here.

bye, Dirk


--
http://www.haun-online.de/
http://www.tinyweb.de/


--__--__--

Message: 10
From: "Tom Willett" <tomw at pigstye.net>
To: geeklog-devel at lists.geeklog.net
Date: Mon, 12 Jul 2004 21:38:18 +0000
Subject: [geeklog-devel] Brainstorming -- Spam Comment API
Reply-To: geeklog-devel at lists.geeklog.net

Talking to Tony on irc about the API needed to make the spamx comment plugin
and related plugins work. Here are some issues which it should address.

Some background -- I implemented the spamx plugin by renaming the savecomment
() function in comment.php to savecomment1 and implementing the savecomment
function in the functions inc, thus hijacking the call to savecomment. The
question is how to implement a plugin API to address this and other possible
plugins.

Issue 1: Since spamx was the only plugin access the savecomment function I
did not bother to return to the function if I wanted to simply drop the
comment. A well behaved plugin should not do this. It should return some
error code to the core code for the core code to decide what to do with it.

Issue 2: What about plugins that might want to alter the comment text and
return it to the savecomment function?

Issue 3: What about a plugin that might want to do something with the
comment (like moderation) depending on what other plugins had found.

This may be two different APIs depending on how its handled.

By the way the same issues could apply to stories and we may want to
consider a similiar api for stories. One plugin that might implement both
the comment and story APIs would be a smiley plugin.

Thoughts?


--
Tom Willett
tomw at pigstye.net


--__--__--

Message: 11
From: "Tom Willett" <tomw at pigstye.net>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?
Date: Mon, 12 Jul 2004 21:39:52 +0000
Reply-To: geeklog-devel at lists.geeklog.net

I understood that function as part of the base class.

--
Tom Willett
tomw at pigstye.net

---------- Original Message -----------
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Sent: Mon, 12 Jul 2004 23:17:08 +0200
Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?


> Tom,

>

> >The only suggestion that I would make is to make the permissions more

> >flexible. That way if root delegated authority to someone, they too

could

> >access the script.

>

> I think this function already handles this nicely:

>

> >> function userCanRunScript()

> >> {

> >> if (!SEC_inGroup('Root')) {

> >> return false;

> >> }

> >> return true;

> >> }

>

> The scriptlet could implement any authentication it wants here.

>

> bye, Dirk

>

> --

> http://www.haun-online.de/

> http://www.tinyweb.de/

>

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

------- End of Original Message -------


--__--__--

Message: 12
Date: Mon, 12 Jul 2004 16:47:21 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?
Reply-To: geeklog-devel at lists.geeklog.net



>Not sure about this one, but do we want to support more than one function

>per scriptlet? Or would those go into separate scriptlets?

>

>

runScriptlet() can act as a proxy method. It is the starting point for
processing so you could have:

function runScriptlet()
{
global $HTTP_POST_VARS;

if (isset($HTTP_POST_VARS['someVariable'])) {
$this->_runFunctionA();
} else {
$this->_runFunctionB();
}
}

function _runFunctionA()
{
// Custom process for handling POST data
}

function _runFunctionB()
{
// Default (i.e. non-POST) processing
}


>Also, what about POST requests? How do they come back into the scriptlet?

>

>

Above example should address this too.


>Outside of the webtree makes sense. Not sure about the database, as it

>also beats the "simple installation" idea.

>

>

Uh, I don't agree. The only attributes in a database table would be:
script_id(auto_increment)
script_className
script_version
script_author
script_long_desc
script_short_desc
been_ran (bit) -> this indicates the script has been ran at least once
enabled_flag (bit)
[insert security fields here]

All that stuff would come right out of the class definition so the
installation would be easy:

<?php

// Get tmp file location
$fileToInclude = [..];

// Include it
require_once $fileToInclude;

// Get class name
$className = [...];

// Instantiate class
$myObj = new $className();

// Delete scriptlet if it already exists
DB_query("DELETE FROM {$_TABLES['scriptlet']} WHERE script_className =
'$className');

//Add it to scriptlet table:
$sql = sprintf("INSERT INTO ? (script_className, script_version,
script_author, script_long_desc, script_short_desc, been_ran, enabled)
values ('?','?','?','?','?',?,?)",
$_TABLES['scriptlet'], $className, $myObj->getVersion(),
$myObj->getAuthor(), $myObj->getLongDesc(), $myObj->getShortDesc(), 0, 1);
DB_query($sql);

?>


>I don't really see any file permission issues. The scriptlets are

>probably included(?) or they're simple .php files.

>

>

Well, the directory they'd go in would need to be writeable. Again, I'd
prefer the database if for no other than to make upgrades easier, but
that's just my to cents.

--Tony


--__--__--

Message: 13
Date: Mon, 12 Jul 2004 16:50:14 -0500
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?
Reply-To: geeklog-devel at lists.geeklog.net

Right, so (and, yes, I'm stating the obvious) if child scriptlets don't
implement that method then Root is required. If a child scriptlet wants
to handle security in a different way they simply override that.

--Tony

Tom Willett wrote:


>I understood that function as part of the base class.

>

>--

>Tom Willett

>tomw at pigstye.net

>

>---------- Original Message -----------

>From: "Dirk Haun" <dirk at haun-online.de>

>To: <geeklog-devel at lists.geeklog.net>

>Sent: Mon, 12 Jul 2004 23:17:08 +0200

>Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?

>

>

>

>>Tom,

>>

>>

>>

>>>The only suggestion that I would make is to make the permissions more

>>>flexible. That way if root delegated authority to someone, they too

>>>

>>>

>could

>

>

>>>access the script.

>>>

>>>

>>I think this function already handles this nicely:

>>

>>

>>

>>>> function userCanRunScript()

>>>> {

>>>> if (!SEC_inGroup('Root')) {

>>>> return false;

>>>> }

>>>> return true;

>>>> }

>>>>

>>>>

>>The scriptlet could implement any authentication it wants here.

>>

>>bye, Dirk

>>

>>--

>>http://www.haun-online.de/

>>http://www.tinyweb.de/

>>

>>_______________________________________________

>>geeklog-devel mailing list

>>geeklog-devel at lists.geeklog.net

>>http://lists.geeklog.net/listinfo/geeklog-devel

>>

>>

>------- End of Original Message -------

>

>_______________________________________________

>geeklog-devel mailing list

>geeklog-devel at lists.geeklog.net

>http://lists.geeklog.net/listinfo/geeklog-devel

>

>



--__--__--

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


End of geeklog-devel Digest

More information about the geeklog-devtalk mailing list