Ok, but assuming we went down that route, I don't quite see how that
side-steps the need to validate users against whether they have
permissions with a particular Trac instance. Currently, we're validating
against the root, and then if a user tries to access a project they're
not a part of, they simply get a error telling them they don't have
WHATEVER_VIEW permissions for that project.
Ideally, we'd have some central database containing usernames and
project-access permissions, but the fact that each Trac instance has
it's own DB, and that those DBs doesn't actually contain much in the way
of user-data makes that solution something of a PITA.
Is it possible to access any of the information Apache/Mod Python passes
in within the 'send_project_index' context. (i.e. the username). If that
is, it'd be fairly trivial to filter based on whether such-and-such a
username has an entry in a particular project.
On 19/4/2010 1:25 PM, Noah Kantrowitz wrote:
The problem is Trac sessions are unique to an instance, so they don't
work outside that context. If you are just requiring HTTP login on the
base URL, you might be able to do something very custom, but it is
probably just easier to grab your favorite webapp framework and write
something in that.
--Noah
On Apr 18, 2010, at 5:55 PM, Josh Godsiff wrote:
Is there no way to retrieve the permissions from within that context?
The code in that section suggests each enviroment is instantiated in
order to pull data from it. Or am I looking at this from the wrong
side, and it's the authentication information that is unavailable,
and not the permissions themselves?
We'd like to avoid setting up some sort of 'main' Trac instance, if
possible, since our eventual aim is to do some fairly complicated and
involved things which I imagine would be quite painful/cludgy to
shoehorn into Trac's individual Project system.
Thanks
- Josh
On 16/4/2010 5:38 PM, Itamar O wrote:
Maybe you can set up a "main company Trac site"
that will function as a "gateway" for clients.
In the main Trac you can build custom lists of projects
linking the their respective Trac sites, and assign permissions
to the lists to your clients (using e.g. [1]).
If you're looking for something fancier, you can probably write
your own plugin (macro?) in that main Trac site that will generate
the project list dynamically based on authenticated user permissions.
Your list-generating plugin can use the XmlRpcPlugin [2] to iterate
over the available Trac sites, and check permissions against them.
Itamar.
[1] http://trac-hacks.org/wiki/PrivateWikiPlugin
[2] http://trac-hacks.org/wiki/XmlRpcPlugin
On Fri, Apr 16, 2010 at 9:02 AM, Noah Kantrowitz
<[email protected]> wrote:
The project index exists outside of the context of an actual Trac,
so nothing that fancy exists. I think I got the TracForge subproject
thingy working in 0.11, so I suppose thats an option. Beyond that,
you would have to build your own little webapp for this.
--Noah
On Apr 15, 2010, at 6:43 PM, Josh Godsiff wrote:
> My company is working on extending the functionality of Trac so we
can use it as a bug-tracking system for out clients' problems (as
opposed to just our internal tracker).
>
> We'd like to extend the Project Index page to show all the
projects for which a particular user (authenticated using the usual
Apache-based authentication mechanisms) has any permissions to view.
>
> Can anyone suggest a good solution for handling this? I've tried
testing against req.perm and req.authname in the
'send_project_index' function of /web/main.py, however, neither of
these variables apparently exist in this context, and I don't know
enough about Trac's inner workings to troubleshoot that.
>
> Thanks
> - Josh
>
> --
> You received this message because you are subscribed to the Google
Groups "Trac Development" 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-dev?hl=en.
>
--
You received this message because you are subscribed to the Google
Groups "Trac Development" 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-dev?hl=en.
--
You received this message because you are subscribed to the Google
Groups "Trac Development" 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-dev?hl=en.
--
You received this message because you are subscribed to the Google
Groups "Trac Development" 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-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups "Trac
Development" 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-dev?hl=en.
