[Trac] Re: Authorization against ActiveDirectory

2007-11-14 Thread Wilson, Bruce E.

I added some text about a configuration I have on one server, where I
needed to authenticate to the LDAP provider.  It's not a perfect answer,
by any means, but it's a useful one.

Rainer -- thanks much for getting this started.



Bruce E. Wilson ([EMAIL PROTECTED]) 
Environmental Sciences Division 
Oak Ridge National Laboratory  
(office) +1-865-574-6651

-Original Message-
From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED]
On Behalf Of Jani Tiainen
Sent: Wednesday, November 14, 2007 4:40 AM
To: trac-users@googlegroups.com
Subject: [Trac] Re: Authorization against ActiveDirectory


Rainer Sokoll kirjoitti:
 Hi,
 
 since the question is asked over and over, I wrote a little HOWTO:
 http://trac.edgewall.org/wiki/ActiveDirectory
 I am sure there is room for improvement, so feel free to 
 alter/enhance/edit/whatever the article.

Thank you very much, I'm in process of setting up AD auth and this saved
some trial and error cycles... :)

-- 

Jani Tiainen



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
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
-~--~~~~--~~--~--~---



[Trac] Re: How do I secure trac from anonymous users?

2007-07-17 Thread Wilson, Bruce E.

Admittedly, I'm using a different environment than you are, but mine
seems to accomplish what I think you're looking for.  What we've done is
configure access to the Trac (and Subversion) sites using mod_ldap in
Apache and then a list of require user statements that are driven
through include files in the conf.d directory for httpd.  What that does
is stop anybody who's not authorized at the apache door.

The next step is that Apache is configured with custom 404 and 403 error
pages.  The 403 (Forbidden) page is set up to generate a 404 status
code.  That then means that someone probing the site gets the same 404
status code whether the file doesn't exist or the file access is
forbidden.  I haven't prodded this a lot, but it seems to work just
fine.

This is, admittedly, also on an Intranet environment.  We are, however,
looking at setting up an alias to this server which will be Internet
accessible, so getting the same thing you're looking for is fairly
important to me.  None of my work is sensitive, so the collaboration can
ge done on the Internet with SSL encryption (in fact, my group's job is
to make some NASA Earth Science data available to the general public),
but I also don't want the general public knocking around in the
collaboration areas we're setting up with some partners in this earth
science data distribution business.

Hope this helps.



Bruce E. Wilson ([EMAIL PROTECTED]) 
Environmental Sciences Division 
Oak Ridge National Laboratory 



-Original Message-
From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED]
On Behalf Of Emin
Sent: Tuesday, July 17, 2007 3:58 PM
To: Trac Users
Subject: [Trac] Re: How do I secure trac from anonymous users?


Thanks for the reply. But even with password authentication turned on,
it seems like an unauthenticated user can still do things like probe
which urls exist and which don't. I guess this isn't a big deal, but it
made me wonder if there was some way to prevent that as well. I guess if
I need that I should look into the apache methods of restricting
access...

Thanks,
-Emin

On Jul 17, 1:17 pm, Jason Winnebeck [EMAIL PROTECTED] wrote:
 If you are using password authentication already, and don't allow 
 non-authenticated use of Trac, then about the only thing more that I 
 can see is to use SSL to serve Trac pages if you are not already, and 
 if you are concerned about password hacking you could go as far as SSL

 client certificates, but that is hard to set up.

 So, in short:
  * Authentication helps to protect you against unsolicited visitors
  * SSL encryption helps to protect you against eavesdroppers
  * SSL client certificates help to protect you against crackers

 Jason



 -Original Message-
 From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED]

 On Behalf Of Emin
 Sent: Tuesday, July 17, 2007 10:37 AM
 To: Trac Users
 Subject: [Trac] How do I secure trac from anonymous users?

 Dear Experts,

 How do I ensure that only users with valid logins have access to my 
 trac instance? I removed all permissions from the anonymous user and 
 followed the instructions in the install guide to use htpasswd to 
 provide authenticated accounts to users. But it seems like it may/ 
 should be possible to secure things further. What else can/should I do

 to protect a trac instance accessable on the Internet as opposed to an

 Intranet.

 Thanks,
 -Emin- Hide quoted text -

 - Show quoted text -




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
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
-~--~~~~--~~--~--~---



[Trac] Ignore common CamelCase words

2007-07-04 Thread Wilson, Bruce E.
The basic problem is that I have certain words in the Wiki that are
often typed in CamelCase, e.g. JavaScript.  I can go through and edit
these to something like !JavaScript to prevent the linkifying, and I see
a mechanism in the config file for ignore missing links.  I could also
create pages for these words, but then they'd show up as links, which I
find distracting (particularly since I have nothing useful to say about
JavaScript in my internal wiki inside of Trac).
 
What I'd like is some mechanism to specify a list of stop words that
aren't linkified, but I've not found anything that does that.  I don't
want to turn off highlighting of missing links, because that's a useful
feature.  I searched trac and trac-hacks, but didn't find anything that
seemed relevant, other than a thought that some type of a macro might be
useful.  Never having tried writing a macro for this, I'm not quite sure
where to start.
 
So, did I miss something in searching -- is there an answer for this
already?  If not, what are the thoughts about the best approach to
tackling this issue?
 



Bruce E. Wilson ([EMAIL PROTECTED]) 
Environmental Sciences Division 
Oak Ridge National Laboratory 

 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
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
-~--~~~~--~~--~--~---



[Trac] Re: LdapPlugin: user_rdn support for users in several OUs?

2007-06-06 Thread Wilson, Bruce E.
We're using LDAP as well.  It's a bit of a hack, but what I've done is
use an Include file that has a set of require user and require group
directives.  I've built a database table, and the list is generated from
that table with a cron job.  Doing it this way -- with the include file
-- lets me use the same file in both the SubVersion section of the conf
files and the Trac section.  I'm actually managing three different
SubVersion repositories and two related Trac instances.


Bruce E. Wilson ([EMAIL PROTECTED]) 
Environmental Sciences Division 
Oak Ridge National Laboratory 
 



From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED]
On Behalf Of Jim Page
Sent: Wednesday, June 06, 2007 3:41 AM
To: trac-users@googlegroups.com
Subject: [Trac] LdapPlugin: user_rdn support for users in several OUs?



Morning All

 

My problem: I am using LdapPlugin to manage my Trac permissions, and
it's great. However our AD structure has users assigned to various
different OUs, Technical, Sales, Management and so on. The Groups I am
using to assign permissions are in the Technical OU (which I set up in
group_rdn), and all works fine, as long as the users themselves are in
the OU I set up in the 'user_rdn=' config entry. But there are several
users in other OUs I would like to allow in, including (rather urgently)
the Technical Manager (who is in OU=Management). Is this currently
supported in any way?  Grasping at straws, I tried 'OU=*' in user_rdn
:-) but it didn't work of course.

 

All help gratefully received.

 

In the event that this is not currently supported, I am considering the
idea of patching LdapPlugin to allow an array of RDNs in user_rdn -
anyone care to comment on that idea, is it a desirable feature for
anyone except me? Is there a better way to do this?

 

All the best

Jim

 

Jim Page

Chief Technical Architect

Email Systems Ltd

Telephone: +44 (0) 870 141 7070

Facsimile: +44 (0) 870 141 8080

www.emailsystems.com http://www.emailsystems.com  - robust messaging
technology

 





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
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
-~--~~~~--~~--~--~---



[Trac] Automated submission of a ticket

2007-06-06 Thread Wilson, Bruce E.
We have an application that collects information from our users and has
an internal (fairly brain-damaged) ticketing system.  The application is
a collection of perl CGI scripts.  I'd like to alter that application so
that it submits the tickets into Trac.  For a number of reasons, I'd
rather that the end users weren't in Trac -- we have enough information
to fill out the ticket and do an initial assignment.
 
I've found one mechanism, which is an e-mail gateway
(http://trac.edgewall.org/browser/trunk/contrib/emailfilter.py?rev=lates
t
http://trac.edgewall.org/browser/trunk/contrib/emailfilter.py?rev=lates
t ).  We looked at the idea of just filling out the Post fields, but
there's the issue of the session ID.  
 
I'm still pretty early on with the learning curve here (my two instances
mentioned in my earlier note are both about a week into production
usage).  I've done some searching, but haven't really found what I'd
consider a good idea.  
 
Suggestions?  Thanks.
 



Bruce E. Wilson ([EMAIL PROTECTED]) 
Environmental Sciences Division 
Oak Ridge National Laboratory 

 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac 
Users group.
To post to this group, send email to trac-users@googlegroups.com
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
-~--~~~~--~~--~--~---