On Tue, Jan 20, 2009 at 11:34 AM, Ruben O <[email protected]> wrote: > > Hi >
Hello ... > I don't understand a lot of things :p): ... well ... that happens to me too ... the only thing I am really sure about is that Trac is great ... :P ... > > To login to TRAC, you need to add a user through httpasswd -m /path/to/ > proyect username and combinating Apache setup, you can ... ask for a > password with directive AuthUserFile /srv/trac/project.htpasswd. > Security can be seen from different perspectives ... first you have user login methods (e.g. Basic/Digest Auth, ...), next you have user credentials (e.g. httpasswd, MS AD, LDAP, Local Windows Accounts, ...), next you have permissions and authorization (e.g. TRAC_ADMIN, WIKI_MODIFY ... and maybe even OAuth ;), and so on ... e.g. user groups, etc ... It is also possible to see in practice further layers (e.g. CoSign ;) > But Trac have a DB users on SQLite, the users who really have > permissions to do somehting on TRAC, so the users of Apache(when you > login to trac) and users of DB SQLite are not the same, aren't they? > Trac separates these concepts. There should be a login module to handle user login. There are AuthStores to validate user credentials. This process may be handled by Trac itself ... but could also be delegated to the web-server hosting the Trac instance using the WSGI standard library REMOTE_USER (... AFAICR ...). this kind of auth delegation, for example, makes Trac integration with CoSign filters relatively smooth ... since there is a very well established separation of concerns, and a standard way to communicate user ids. BTW ... there are permissions (i.e. PermissionSystem ...) ... which are defined on a per-user/group basis. In this case Trac stores user permissions in the env's database, since their semantics (meaning ...) is quite related with the core services and those provided by extensions (e.g. XMLRPC ...). Nonetheless group membership and so on can be retrieved from elsewhere (e.g. LDAP dir ;). The connection between these two sub-systems is given by the user names in Trac's DB matching the value assigned at run-time to the REMOTE_USER variable (which is set by the auth provider ... i.e. an specific Trac component or third-party apps, let's say web servers ...). This means that Trac implementation is not strongly coupled to any security infrastructure you could ever imagine ... Conclusions ... Trac is great ! ... ;) > I think is a confusing topic, Ooops ... are computer scientist the masters of chaos ? :) > but Im very newbie with TRAC. Hope you have learned a little bit ... ;) Moreover there should be at least some other references about this particular subject. I mean something about WSGI security architecture ... > Because to > add a normal user to Trac, first you need to add user and password > through htpasswd and later create the same user in Trac(the user is > created then on DB with permissions). > This is not compulsory ... you could do any of them any time, you could even migrate your server and have no (or an empty ;) auth store but user permissions will be there ... > Sorry by newbie questions. > The best way to learn is to ask ... :) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
