11:10 a.m.
I'm setting up a hosting proof of concept, and trac uses web authentication
for users. Anybody got some ideas on how to tie into our account system for
this?
--
Jesse Keating
Release Engineer: Fedora
11:43 a.m.
On 11/19/06, Jesse Keating <jkeating(a)redhat.com> wrote:
I'm setting up a hosting proof of concept, and trac uses web
authentication
for users. Anybody got some ideas on how to tie into our account system for
this?
--
Jesse Keating
Release Engineer: Fedora
<Location /path>
Options ExecCGI
AuthType Basic
AuthName "You want in? GET A PASSWORD!"
Auth_PG_host db1
Auth_PG_port 5432
Auth_PG_user apache
Auth_PG_pwd ASKMEFORPASSWORD
Auth_PG_database fedorausers
Auth_PG_pwd_table person
Auth_PG_uid_field username
Auth_PG_pwd_field password
Auth_PG_encrypted off
Require user jkeating mmcgrath
# or
# Require valid-user
</Location>
8:31 p.m.
FWIW, a final implementation would optimally be a little more
complicated than this:
. It should only give access to people whose accounts are in
'approved' status (not many aren't, but still...)
. It should only give access to people who have approved access in a
particular group (e.g. 'tracusers' in this case)
so that we can use the account system to authorize users...
-- Elliot
<Location /path>
Options ExecCGI
AuthType Basic
AuthName "You want in? GET A PASSWORD!"
Auth_PG_host db1
Auth_PG_port 5432
Auth_PG_user apache
Auth_PG_pwd ASKMEFORPASSWORD
Auth_PG_database fedorausers
Auth_PG_pwd_table person
Auth_PG_uid_field username
Auth_PG_pwd_field password
Auth_PG_encrypted off
Require user jkeating mmcgrath
# or
# Require valid-user
</Location>
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
9:07 p.m.
On 11/19/06, Elliot Lee <sopwith(a)gmail.com> wrote:
FWIW, a final implementation would optimally be a little more
complicated than this:
. It should only give access to people whose accounts are in
'approved' status (not many aren't, but still...)
. It should only give access to people who have approved access in a
particular group (e.g. 'tracusers' in this case)
so that we can use the account system to authorize users...
-- Elliot
This actually isn't terribly difficult to set up with pgsql but we'll
have to alter our database a bit. If the time comes and the new
accounting system isn't ready we can make these alterations.
-Mike
7:11 a.m.
On Sunday 19 November 2006 21:31, Elliot Lee wrote:
FWIW, a final implementation would optimally be a little more
complicated than this:
. It should only give access to people whose accounts are in
'approved' status (not many aren't, but still...)
. It should only give access to people who have approved access in
a particular group (e.g. 'tracusers' in this case)
so that we can use the account system to authorize users...
I think this sounds pretty sane. Getting approved for trac should be as
simple as having the CLA complete, or something similar. I think its a good
policy discussion to see if we want to involve the CLA for project hosting.
I know its stifled some of the work in Kadischi according to some of the
users that would like to contribute but don't want to go down the CLA route.
Also Trac can be used pretty easily in anonymous mode.
--
Jesse Keating
Release Engineer: Fedora
5:43 p.m.
On Nov 20, 2006, at 8:11 AM, Jesse Keating wrote:
On Sunday 19 November 2006 21:31, Elliot Lee wrote:
> FWIW, a final implementation would optimally be a little more
> complicated than this:
> . It should only give access to people whose accounts are in
> 'approved' status (not many aren't, but still...)
> . It should only give access to people who have approved
> access in
> a particular group (e.g. 'tracusers' in this case)
> so that we can use the account system to authorize users...
I think this sounds pretty sane. Getting approved for trac should
be as
simple as having the CLA complete, or something similar. I think
its a good
policy discussion to see if we want to involve the CLA for project
hosting.
I know its stifled some of the work in Kadischi according to some
of the
users that would like to contribute but don't want to go down the
CLA route.
Also Trac can be used pretty easily in anonymous mode.
Thinking about it some more (now that I realized it's in the context
of hosting projects) - you're going to want to have a separate
account system group for each hosted project.
I don't know whether it's the CLA or something else, but you should
work with RH Legal to make sure that there is some sort of legal
agreement in place between the project contributors and Red Hat to
define the relationship.
Best,
-- Elliot
9:07 p.m.
On Monday 20 November 2006 18:43, Elliot Lee wrote:
Thinking about it some more (now that I realized it's in the
context
of hosting projects) - you're going to want to have a separate
account system group for each hosted project.
Why would that be? At least with trac, all fedora users are treated the same
as anonymous, but you could get your name attached to a bug (and thus emails)
and wiki changes. Account privilege escalation can be done within the Trac
instance itself, through the webadmin tool. Why would we need a different
account system? Why wouldn't the Fedora account system work and just allow
any user that has CLA signed to create a project or login to participate with
a name to an existing project?
--
Jesse Keating
Release Engineer: Fedora
7:34 p.m.
On Nov 20, 2006, at 10:07 PM, Jesse Keating wrote:
On Monday 20 November 2006 18:43, Elliot Lee wrote:
> Thinking about it some more (now that I realized it's in the context
> of hosting projects) - you're going to want to have a separate
> account system group for each hosted project.
Why would that be? At least with trac, all fedora users are
treated the same
as anonymous, but you could get your name attached to a bug (and
thus emails)
and wiki changes. Account privilege escalation can be done within
the Trac
instance itself, through the webadmin tool. Why would we need a
different
account system?
(To recap, I suggested a different account system _group_, not an
entirely different account system.)
Why wouldn't the Fedora account system work and just allow
any user that has CLA signed to create a project or login to
participate with
a name to an existing project?
I think that works within the context of Fedora as a whole, but
moving into hosted territory means you have to adopt more of a
sourceforge mentality, where your job is to give as much control as
possible to the project owner, and let them make decisions such as
who can participate. In order to let each project owner make access
decisions independantly, you would need a separate account.
It sounds like trac has some 'webadmin' thing for controlling
people's access - I think it's a bad idea to go with that. Properly
tying trac into the Fedora account system means making it so that
full control of both authentication & authorization is done through
the FAS. In the long run, it'll be a lot nicer to be able to go to
one place to control people's access levels for everything. (Not to
say that FAS v1 is the right way to do it, just suggesting a good
goal for the future :)
Best,
-- Elliot
3:53 p.m.
On Tuesday 21 November 2006 20:34, Elliot Lee wrote:
I think that works within the context of Fedora as a whole, but
moving into hosted territory means you have to adopt more of a
sourceforge mentality, where your job is to give as much control as
possible to the project owner, and let them make decisions such as
who can participate. In order to let each project owner make access
decisions independantly, you would need a separate account.
I'm still not so sure you would. For a source repo, there would be a new
group, and the existing user who is the admin for a project would be made the
admin of this group. (S)He could then approve/deny requests to join the
source group for write access.
It sounds like trac has some 'webadmin' thing for controlling
people's access - I think it's a bad idea to go with that. Properly
tying trac into the Fedora account system means making it so that
full control of both authentication & authorization is done through
the FAS. In the long run, it'll be a lot nicer to be able to go to
one place to control people's access levels for everything. (Not to
say that FAS v1 is the right way to do it, just suggesting a good
goal for the future :)
This _may_ be possible in the future, however the only real authorization that
we need to set in Trac is the initial admin. The trac webadmin is mostly for
setting up urls and project summaries, and ticket components, milestones,
etc.. All of this is highly trac instance specific. There _is_ some
management of who can open/close bugs I do believe, and who is a default
owner of bugs, but again its all instance specific. I think for the first
instance of Fedora Hosted Projects this would be perfectly serviceable and if
problems arise we can look at fixing them, or more tightly integrating trac
with FAS v2 for Fedora Hosted Projects v2.
--
Jesse Keating
Release Engineer: Fedora
6363
days inactive
6366
days old
infrastructure@lists.fedoraproject.org
8 comments
3 participants
participants (3)
-
Elliot Lee -
Jesse Keating -
Mike McGrath