Hi,
On Sat, 05 Dec 2009 21:25:59 +0100, "Steve" <steeeeev...@gmx.net> wrote: > -------- Original-Nachricht -------- >> Datum: Sat, 5 Dec 2009 21:13:04 +0100 >> Von: "Imposit.com - Webmaster" <webmas...@imposit.com> >> An: dspam-devel@lists.sourceforge.net >> Betreff: Re: [Dspam-devel] Control multiple users from one login on >> web-ui > >> 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 >> > Depends on the implementation. I general the DSPAM_HOME has just one > uid/gid. I don't know how it is with enabled home dir. Do you know that? That's my point, like mayor servers today had virtual users, and dspam has their propietary permissions to run under their propietary home with their uid/gid, no breach could be made, except in the case all spam as important role in your organization. and admin could not check all spam in the spam quarantine storage. edgar > > >> >> >> 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