[Trac-dev] Re: REMOTE_USER change

On Jul 31, 2007, at 6:42 PM, Graham Dumpleton wrote:

> Note that the standard way that Apache authentication modules are
> supposed to work is that they set req.user to the authenticated user
> id. This is also turned into REMOTE_USER variable in
> req.subprocess_env when req.add_common_vars() is called. If
> add_common_vars() isn't being called by a mod_python handler you will
> thus not have access to REMOTE_USER and would have to use req.user.
>
> FWIW, you seem to deliberately doing things to break how Apache
> normally works. Why can't your other module simply set req.user in the
> correct manner to what you want rather than using the request
> environment variables. If the module is a C module it is the 'user'
> attribute of request_rec structure. If you need whether this is done
> to be selectable then add a directive to enable passing full name in
> req.user. Do note though that your full names better be unique
> otherwise you might have issues in Trac.
>
> Perhaps provide more explanation of the reasons for wanting to so
> this, rather than simply what you want to achieve. It may be the case
> that you shouldn't be changing Trac but that the other module should
> be changed to do things in a more customisable way inline with how
> Apache should be used.

Actually our module is setting REMOTE_USER correctly, but to provide  
backwards compatibility the name being put into that field is missing  
some important information. Our web authentication system was  
recently upgraded to support multiple realms of users, for example  
alumni, pre-admission students, and general community members.

[Trac-dev] Re: REMOTE_USER change

On Aug 1, 11:39 am, "Stephen A. Cochran Lists"
<stephen.a.cochran.li... <at> cahir.net> wrote:
> On Jul 31, 2007, at 6:42 PM, Graham Dumpleton wrote:
>
>
>
> > Note that the standard way that Apache authentication modules are
> > supposed to work is that they set req.user to the authenticated user
> > id. This is also turned into REMOTE_USER variable in
> > req.subprocess_env when req.add_common_vars() is called. If
> > add_common_vars() isn't being called by a mod_python handler you will
> > thus not have access to REMOTE_USER and would have to use req.user.
>
> > FWIW, you seem to deliberately doing things to break how Apache
> > normally works. Why can't your other module simply set req.user in the
> > correct manner to what you want rather than using the request
> > environment variables. If the module is a C module it is the 'user'
> > attribute of request_rec structure. If you need whether this is done
> > to be selectable then add a directive to enable passing full name in
> > req.user. Do note though that your full names better be unique
> > otherwise you might have issues in Trac.
>
> > Perhaps provide more explanation of the reasons for wanting to so
> > this, rather than simply what you want to achieve. It may be the case
> > that you shouldn't be changing Trac but that the other module should
> > be changed to do things in a more customisable way inline with how
> > Apache should be used.
>
> Actually our module is setting REMOTE_USER correctly, but to provide

[Trac-dev] Re: REMOTE_USER change

On Jul 31, 2007, at 9:53 PM, Graham Dumpleton wrote:

> As I mentioned briefly in my comments, would you be able to implement
> a directive for your module which can be set to enable/disable
> req.user being set to the full name with realm.
>
> Presuming that Trac user database has full name with realm in it, you
> could then say:
>
>   <Location /trac>
>   StuffFullNameInUser On
>   </Location>
>
> Ie., turn on passing of full name just for URL Trac is under.
>
> This will allow you to selectively pass through the extra information
> to applications as user databases are updated.
>
> Not sure I have got this round the right way, so I hope you understand
> what I am talking about. Or am I missing something.

Yep, I think I understand. Basically adding the option to the apache  
module to set REMOTE_USER to the username <at> realm form via directive.  
It's not a bad feature to add to the module, I just thought it would  
be easier to change the spot in trac that was pulling the REMOTE_USER  
param, I just couldn't find it or figure out the new form.

Steve

http://www.pakhostonline.com/

[Trac-dev] 0.11 Bug or feature? redirect in process_admin_request

Hi, 

I'm currently migrating some plugins to Trac 0.11.

My admin plugin is still using the process_admin_request method, and
when I try:

req.redirect(self.env.href.admin(cat, page))

the browser is redirected to:

http://host/admin/projectmanager/properties

instead of 

http://host/trac/project/admin/projectmanager/properties

(so the "trac/project" part is missing).

The same sentence is used in trac code and it works. For example in
BasicAdminPanel:

    def render_admin_panel(self, req, cat, page, path_info):
        req.perm.require('TRAC_ADMIN')

        if req.method == 'POST':
            for option in ('name', 'url', 'descr'):
                self.config.set('project', option, req.args.get(option))
            self.config.save()
            req.redirect(req.href.admin(cat, page))

Am I doing something wrong, or is there something wrong with the
req.href object passed to process_admin_request? 

Thanks very much.

--

-- 
--------------------------------------

        Álvaro J. Iradier Muro
     alvaro.iradier <at> intelcard.com

   AM&B - Dept. de Desarrollo e I+D

[Trac-dev] Re: 0.11 Bug or feature? redirect in process_admin_request

Am 03.08.2007 um 11:31 schrieb Álvaro J. Iradier Muro:
> I'm currently migrating some plugins to Trac 0.11.
>
> My admin plugin is still using the process_admin_request method, and
> when I try:
>
> req.redirect(self.env.href.admin(cat, page))

You should be using req.href everywhere you have a "req" object  
available.

In 0.11, the environment only knows about the path if the user  
explicitly configures it in trac.ini, otherwise it'll assume it's  
running on /.

If you use req.href, however, it'll use the information it has  
available through the request object to determine the correct URL.

req.href has been available since 0.10.

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Carters += 1

I am happy to report Samuel Carter was born at 3:17am. I hope everyone
will join me in congratulating Eli on another fine addition to the
Carter clan, and wish him luck in surviving the next several weeks!

--Noah

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Carters += 1

Hear hear!

Congratulations Eli and clan :)

On 8/4/07, Noah Kantrowitz <kantrn <at> rpi.edu> wrote:
>
> I am happy to report Samuel Carter was born at 3:17am. I hope everyone
> will join me in congratulating Eli on another fine addition to the
> Carter clan, and wish him luck in surviving the next several weeks!
>
> --Noah
>
> >
>

--

-- 
Evolution: Taking care of those too stupid to take care of themselves.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] [i18ln] starting

Hi All

I'll start tomorrow a translate locale files in branch i18ln ( pt_BR
locale)

How active locale to a trunk env previously created.

I tried copy of  dir /trac/locale to /usr/lib/python2.4/site-packages/
Trac-0.11dev_r5892-py2.4.egg/trac/

but doesn't work.

Cheers

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Carters += 1

On Friday 03 August 2007, Noah Kantrowitz wrote:
> 
> I am happy to report Samuel Carter was born at 3:17am. I hope everyone
> will join me in congratulating Eli on another fine addition to the
> Carter clan, and wish him luck in surviving the next several weeks!

Thanks, all.  :)

Eli
/me mumbles something groggy about night feedings...

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---