Ok but the user has no right tot he mbox file.
Maybe im wrong but I thought the credentials needed to get rights on the mbox
file trough suexec
Von: Edgar Díaz Orellana [mailto:eorel...@fulltimehosting.net]
Gesendet: Samstag, 05. Dezember 2009 21:07
An: dspam-devel@lists.sourceforge.net
Betreff: Re: [Dspam-devel] Control multiple users from one login on web-ui
Hi.
I guess just create 3 tables on mysql engine, with only that you could create
all type of group, users and joins.
like
Table A (Users) Table B (Joins ) Table C (
Groups )
r...@localhost Admin
(* all users)
ad...@localhost Admin (*
all users)
ad...@somedomain 1
ad...@somedomain
j...@somedomain 1
ot...@somedomain 1
u...@somedomain 1
otheru...@somedomain 1
Then when ad...@somedomain logons, could admin all users there could admin.
and so on.
Just think about
On Sat, 05 Dec 2009 16:49:37 +0000, Paul Cockings <ds...@cytringan.co.uk> wrote:
I think flat file is absolutely okay (woof woof)
LOL
So if I really wanted this then maybe a 3rd file then called 'manager.cgi' that
obeys a simple flat file?
'Managers' that need this function would use http://my-dspam-install/manager.cgi
User A can control User 1,2,3,4
User B can control User 2,4,6,8
I suppose error handling would have to include missing (or misspelt) using,
null user, missing file, corrupt file
If 'manager' is not in 'flatfile' then user cannot login, they should go use
http://my-dspam-install/users.cgi
'manager' can still login to http://my-dspam-install/users.cgi to control there
own profile (but would only see their profile)
I hear what you say about about this isn't best way and maybe during v4.0
brainstorming will can build this type of thing in... but until then a hack
will work? Maybe as as a /contrib rather then main project?
I am thinking simple ie 'manager' as the login user and can control xyz other
users, no more, no less.
Could I send you a pizza and a large packet of chocolate biscuits to code this
up? I am lost in perl :-(
Pc
Steve wrote:
-------- Original-Nachricht --------
Datum: Sat, 05 Dec 2009 15:44:28 +0000
Von: Paul Cockings
An: dspam-devel@lists.sourceforge.net
Betreff: [Dspam-devel] Control multiple users from one login on web-ui
I have some customers that have multiple address's being filtered by the
same Dspam server. To check each account (they are separate as far as
Dspam is concerned) the end user has to log in as user 1, check account,
close browser, log in as user 2, check account, close browser... /loop/
Is they anything we can easily do to change the web-ui to handle one
user login that can 'manage' several accounts? Note, I don't want
shared/merged groups as these accounts are better left as individual
spam databases.
Currently you can't switch users. Only an administrator can do that. I guess
declaring them as administrators on DSPAM WebUI is not an option?
The WebUI works that way that it checks for the HTTP REMOTE_USER variable and
uses that for active user. That restriction is only relaxed for users that are
in the "admin" file mentioned. Every one else can't switch.
We could relax that for other users but then we would need to have another
source where we need to look for which other user one can switch. Something
like this:
userA (can switch to): userB,userC,userD
I could add something like that but I see it already. I see already 1 million
users then going to ask that we add group functionality into that. Aka:
groupA (can manage): userA,userB,userC
And then I see others asking for:
groupA (can manage): userA,userB,userC
groupB (can manage): userX,userY,userZ
groupC (can manage): groupA,groupB
userA (is member of): groupA
userB (is member of): groupB
userPaul (is member of): groupC
admin (is member of): ALL GROUPS
And then I see others asking for:
groupA (can manage): userA,userB,userC
groupB (can manage): userX,userY,userZ
groupC (can manage): groupA,groupB
groupD (can manage): groupA,groupB,groupC
groupE (can manage): groupC but not members of groupB
And so on and so on.... you can imagine: It would be a never ending story since
every one would at the beginning say that they could live with a flat file and
then they start to fill in bug reports asking for feature A, then feature B and
then for featureC and at the end the flat file solution is ultra terrible to
maintain and very limited to work with and it would have been better to
implement everything with a proper directory (aka LDAP or other solution) then
going the simple road.
But off course. At the beginning everyone and his dog will tell you that a flat
file is absolutely okay and that in NO WAY they would ever want more then that.
In German we have an expression "Mit dem Essen kommt der Appetit".. That means:
With eating comes the appetite.
As soon as you give the small finger they (the users out there) are going to
take/request the whole hand. And I don't know if doing now again a hack on top
of another hack (the hack on top of the hack is the WebUI) is the right
solution?
Pc
Steve
!DSPAM:1005,4b1abe1744111804284693!
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Dspam-devel mailing list
Dspam-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-devel
