> I've done some thinking
about whether we need to add an "admin" bit for members, or something.
Obviously, we can use constraints and filters to protect against most
actions, but there are certain operations (like deleting locations, or
cleaning up spam articles/events/whatever) that really only make sense
for a "privileged" user.
I'm not sure I agree. I think the free-for-all approach works okay. As
long as you have to make an account with a unique and real email address
in order to modify anything, this will keep the most simplistic
(bot-type) spammers at bay. I don't think we have to worry much about a
malicious user creating an account and then deleting all the locations
or something. At very least, if we say that you can't delete a location
that is attached to an event, and only the event owner can delete an
event, then this isn't even a very effective attack.
Regarding deleting spammy articles, currently anyone can delete
anything. I think a good system (but probably a v2.0 thing) would be to
add a relation
CREATE TABLE article_vetoes (
id SERIAL PRIMARY KEY,
article_id INT NOT NULL,
member_id INT NOT NULL
);
Then we can hide articles where "SELECT count(*) FROM article_vetoes
WHERE article_id='thisarticleid'" >= threshold. Also, before a user
"vetoed" some article, we would need to check that the article_id,
member_id pair was unique in this relation.
This brings up another issue: Constraints and referential integrity. My
Rails-fu isn't as good as many of you, but I can't figure out a good way
to enforce referential integrity with Rails. Maybe it would be best to
just have Postgres do it - this would be the fastest/safest solution,
but might be ugly to the user. Perhaps we can do some exception handling
for constraint validation, and have rails pretty-up the error to the
user... Thoughts??? This exploit that the NYC people did wouldn't have
worked if we used normal database practicies and had a few simple
foriegn key constraints.
So, should we add such a flag to the user model, and an interface for
admins to grant and revoke other admins' privs, or stick to using the
console and/or a password-protected alternate site running a bare
scaffold to manage the messy bits?
Well, IMHO, I think the current system works just fine.
--
Caleb Phillips
IT Specialist
Small White Cube
_______________________________________________
PdxRuby-dev mailing list
[email protected]
http://lists.pdxruby.org/mailman/listinfo/pdxruby-dev
