Re: [Simplog-devel] adodb

[<ja...@bu...>]

Jim Hu writes: 

> Can't say about 4.2, but I also put it on my server, which is still 
> running 4.3.  Seems to work with Simplog.  The Sourceforge page says it 
> requires php 4.0.5 or later.

Based on that, I would suggest that we do the upgrade to the latest version 
of ADODB. 

> OK, I figured out the problem.  The index file I had modified uses: 
> 
> <?php @include("$baseurl/blog.php?blogid=$blogid"); ?> 
> 
> which I think was based on an older version of index.php.  Yours uses 
> 
> <?php include("blog.php"); ?>

Aaaah yes. I remember making that change - had to do that to get the session 
data to be preserved. 


> However, there is a design issue regarding the 
> meaning of public, protected, and private that should be resolved before 
> going further - I think that your function changes the meanings...it does 
> so in a way that I sort of agree with, but here's the problem: 
> 
> In the help files, Jeremy defines the three kinds of blogs as follows: 
> 
>>  A new blog can be Public, Protected or Private, and this provides a 
>> method of pre-defining which users can contribute new comments without 
>> explicitly defining each. In a public blog, any user with a logon can add 
>> entries. In a protected blog, any one of a specfic set of users can add 
>> entries, and others are stopped. In a private blog, only one person can 
>> add entries. Regardless of whether the blog is public, protected or 
>> private, everyone can read the blog.

I actually looked for an official definition of what those three things 
meant, but didn't find anything, so I just made up what I thought was 
appropriate (public = anyone, protected = any authenticated, private = user 
on the acl). 

Keep in mind that I haven't implemented any of the protection stuff on the 
insert/update operations in class.BlogInfo or class.BlogEntry yet. 

> With isUserAuthorized, this has changed so that only authorized users can 
> _read_ protected and private blogs.  I think that having blogs that are 
> not accessible to the public is useful, and I took a different approach to 
> get this functionality by adding auth() to the index files for each blog.  
> However, this is trivially defeated by bypassing the index file via 
> http://host/simplog/blog.php?blogid=X, so your solution should be better.  

Well, it's not 'trivially defeated' - because the protection is enforced 
near the data - in class.BlogInfo. That is why the calls to 
isUserAuthorized() were placed there. Which is where the data security 
should be enforced. 

> The problem is - I think your solution breaks something we've been telling 
> users about how to customize their pages - by using blog.php to pass 
> formatted content to the target website.  This means that upgrading to 
> 0.91 may break some existing sites.

Well, it's a bit too late, seeing as 0.9.1 has been released. I haven't seen 
any traffic on the user list to indicate that this has caused problems. 

> It seems to me that it would be better to define the kinds of blogs 
> differently than either of the above, based on four kinds of access 
> permissions: view, comment, post, and administer.  I'm not sure that the 
> current distinction between protected and private is useful, as one could 
> in principle make protected blogs with only one user.  I'd suggest that 
> all kinds of blogs should only allow posts by acl users, and all kinds of 
> blogs should allow administration within a blog by anyone set as an 
> administrator in the blog_acl table (not clear to me that the admin column 
> in blog_acl does anything in current versions).  The site administrator 
> would still have global admin privileges.  In addition, the three kinds 
> would mean:

The only thing missing from the above suggestion is 'simplicity'. Of course 
we could come up with a much richer, more sophisticated ACL implementation. 

The question is: Do users need it? Do administrators want it? Would it 
justify the increase in complexity of the UI? 

If we are to continue to think of simplog as a 'personal blog publishing 
tool', I would think could adopt: 

1. Public - anyone can read, only ACL-users can insert/update/delete.
2. Protected - only ACL-users can read/insert/update/delete
3. Private - ACL-users can read, only owner can insert/update/delete 

 -jason