Ok btu at the momment the user hast he right at least at 3.9.
Anyway I don’t like the idea having an admin right to all files for the webui.
It would be easier to have the mboxes in the mysql table so no bothering about
file rights and sec issues on the system.
Worst case would be a breach to the mysql db
Imposit.com
Phone: +43 (1) 9971636-30
Fax: +43 (1) 9971636-90
E-mail: mailto:webmas...@imposit.com
Web: www.imposit.com
Registered Office: Wienerstrasse 130,
8680 Mürzzuschlag, Austria, Company number FN310087K
Von: Edgar Díaz Orellana [mailto:eorel...@fulltimehosting.net]
Gesendet: Samstag, 05. Dezember 2009 21:18
An: dspam-devel@lists.sourceforge.net
Betreff: Re: [Dspam-devel] Control multiple users from one login on web-ui
But the admin has the same privileges as admin as. like in dspam admin, that
user has no privileges at mailfile at /var/spool/dspam files.
Just it's an idea to create admins for certain domains, or prefer to create
admins for certain accounts at domain or top domain.
edgar
On Sat, 5 Dec 2009 21:13:04 +0100, "Imposit.com - Webmaster"
<webmas...@imposit.com> wrote:
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 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 +0000Von: Paul Cockings An:
dspam-de...@lists.sourceforge.netbetreff: [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,userCgroupB (can manage):
userX,userY,userZgroupC (can manage): groupA,groupBuserA (is member of):
groupAuserB (is member of): groupBuserPaul (is member of): groupCadmin (is
member of): ALL GROUPS And then I see others asking for:groupA (can manage):
userA,userB,userCgroupB (can manage): userX,userY,userZgroupC (can manage):
groupA,groupBgroupD (can manage): groupA,groupB,groupCgroupE (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,4b1ac05950481804284693!
------------------------------------------------------------------------------
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
