RE: [Blogcfc-develop] First big discussion

[Ben F. <bf...@ma...>]

I've been giving this one lots of thought, and honestly, I don't believe
users and passwords belong here at all. In the current distribution, the
first thing I do each time I grab a new build is to comment out the line
of code in Application.cfm which invokes the user authentication method
(and I also do not execute the SQL to create the user table). Why?
Because I already have users and passwords and access control for other
parts of my site and I just reuse those.

Before we add users, and groups and passwords and user management, the
bigger question to ask is why should that be there at all?

Truth is, there is a more fundamental question here, and that is, is
blogcfc an application or an API? It started life as an API, it was a
cfc file that came with an example interface (Ray's index.cfm) and no
admin tool. But it seems to be slowly being pushed into becoming a full
application. There is an important practical difference here - APIs do
not require users and passwords, applications do. The question then is,
should it really be an application or should it remain an API?

My gut feel is the latter, I don't use Ray's UI or admin code, and don't
plan to (I have my own look and feel and my own site admin already).
Having users and passwords is thus bothersome. If most users will not
need multiple blogs or multiple levels of security, or if most users
will create their own interfaces, or if most users already have some
sort of security scheme in place, then they too will find this
bothersome. But others may disagree.

One solution is to separate the two, this will help satisfy both camps.
The core blog is an API, a CFC that can be used as is. It may need a
blog id passed in some init call (and some other settings, the stuff in
the INI file now), but that is it, from that point on it runs as is -
just call methods and it returns data, simple. Then an application can
also be provided (maybe it is Ray's app, or an example, or several
examples) and they introduce other features including users and logins.
That application should isolate all user processing into a single
user.cfc which can be used as is or replaced at will so as to easily
interact with existing security systems.

Bottom line, while I think it is great to support advanced
functionality, I'd hate for the core "drop it and run" simplicity to be
lost in all of this.

--- Ben



-----Original Message-----
From: blo...@li...
[mailto:blo...@li...] On Behalf Of
Raymond Camden
Sent: Thursday, July 31, 2003 11:31 AM
To: blo...@li...
Subject: [Blogcfc-develop] First big discussion


Ok, to start the ball rolling, let's start the first big discussion.
This is already in the tracker, but it's important enough for me to
bring out here.

Currently to 'setup' the blog, you run a sql script and then edit an ini
file. Currently the blog supports one blog per DSN.

The goal is to allow 2 big changes:

	N blogs per 1 DSN.
	N users per 1 DSN. (To allow for group blogs.)

This means a variety of things.

We need the concept of blogs on a DSN.
We need the concept of assigning user Foo to blog A.

Many questions come from this:

First, do we continue to use the ini file? The problem with this is that
when I add my blog to your DSN, I don't know the new primary key
generated. This can be corrected a variety of ways. One way is to just
do a look up. When you work with blog("foo"), we simply do a lookup in
the constructor and remember foo is ID=X. If you cache your blog, this
is very trivial. We can even make it so that when foo doesn't exist, it
auto inserts. 

But then user management is still a pain. Do I do something like this in
my ini file

[foo]
users=jedimaster,goober,doober

If so - where do I store the passwords? Do I use a list within a list?

users=jedimaster:password,goober:password2

This is a major security hole if someone reads blog.ini.

So what I'm thinking is that we need to drop the ini file. I like the
ini file a lot, but if everything is web based, then we can alleviate
some of these worries. However, we still need an ini file to tell us
what DSN to use. If we do _everything_ in the db, it forces us to use
one DSN for _all_ blogs. (Or have multiple copies of blog.cfc each with
it's own <cfset dsn = whatever> line).

Going back to ini file - it _would_ be ok if the ini file was kept out
of the web root. Heck, we could even rename blog.ini to blogini.cfm. Did
you know the INI file functions still work on a file even if it's not
named *.ini? And you can even add

<cfabort>

to the top of the page and it won't screw stuff up. So, this would only
be a security risk if someone got access to the file itself, not via the
web. One nice thing about keeping the ini approach is that it allows me
to remove the users table from the db, making the db even more simple.

We could also store hashes of user passwords in the ini file, but then
I'd need to add a user admin to the client so you wouldn't have to write
a custom CFML file everytime you edit a user.

Forgive the rambling nature of this note. My own thoughts are unsure of
how to support this.

========================================================================
===
Raymond Camden, ColdFusion Jedi Master for Mindseye, Inc
(www.mindseye.com)
Member of Team Macromedia (http://www.macromedia.com/go/teammacromedia)

Email    : jed...@mi...
Blog     : www.camdenfamily.com/morpheus/blog
Yahoo IM : morpheus

"My ally is the Force, and a powerful ally it is." - Yoda 



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01
/01
_______________________________________________
Blogcfc-develop mailing list Blo...@li...
https://lists.sourceforge.net/lists/listinfo/blogcfc-develop