[Trac-dev] Request match "precision" in match_request()

While working on #4878 (Weird URL handling of additional characters on 
the end), which asks that requests to e.g. "/timeline/bogus" either 
return a 404 or a permanent redirect to "/timeline", I've been looking 
at match patterns in match_request(). This has raised a few questions 
for which I would like to get some feedback:

  * Currently, many request handlers match very liberally. For example, 
any request that matches "/admin.*" will be handled by the admin module, 
including "/adminlskjdfkljsd". Is this intentional? If not, shouldn't 
this be fixed?

  * Many handlers allow a trailing /, for example "/newticket" and 
"/newticket/". What is the reason for this? Noah has mentioned this 
being a convenience for people entering URLs that don't know what they 
are doing. Are there any other reasons?

  * The "matching precision" is very variable between handlers. Some 
handlers match only precise URLs (e.g. "/tickets/([0-9]+)$"), others are 
more graceful (e.g. "/report(?:/([0-9]+))?", which will show the list of 
available reports for "/report/bogus").

Is there a rule for how precise a match_request() should be? I see two 
possibilities:

  * Be strict in what a handler accepts. This has the advantage of 
giving a more precise answer for malformed URLs (usually a "No handler 
matched request to ..."). But it is less forgiving for user-entered 
URLs, and might therefore have usability issues. If this option should 
be followed, then a trailing / should probably not be accepted.

[Trac-dev] Re: TicketModerator plugin guidance

would the new workflow be a solution for that too?

On Aug 28, 5:11 am, John Siirola <jsiir...@gmail.com> wrote:
> Folks,
>
> I have been using Trac on some internal projects for coming up on a year
> now, and was just presented with a new project that will require a new
> Trac plugin.  I am new to both Python and Trac internals, so I would
> greatly appreciate any design guidance anyone might offer before I start
> blindly wandering in the dark.
>
> The situation:  There is an open source project that would like to
> switch to Trac.  We would like to support anonymous ticket creates &
> appends.  The catch is the hosting provider is paranoid about ticket
> butchers and content accountability.  The result is that we (by rule)
> can not allow anonymous users to directly edit any publicly-viewable web
> content.
>
> The idea: create a TicketModerator plugin that will take an incoming
> ticket (new or comment) generated by an anonymous user and put it into a
> "holding pen".  It will then notify (e-mail) a dev, and the dev can
> click a link to either accept or reject the submission.
>
> I figure there are at least two possible ways to implement this:
>
> 1) route all anonymous contributions to a custom ticket state, and then
> write a ticket filter that will always hide those tickets from the web
> interface (i.e. queries, reports, browsing, etc).  There are a couple
> problems, though... The hidden tickets / comments will occupy a space in

[Trac-dev] Re: Default admin user creation while creating environment

On Aug 29, 2:48 pm, "Erik Bray" <hyugaricd...@gmail.com> wrote:
> On Fri, Aug 29, 2008 at 1:34 AM, Jani Tiainen <rede...@gmail.com> wrote:
> > I think there should be option to create default "admin" user with
> > "TRAC_ADMIN" rights. Recently there has been increasing amount of "can't
> > find admin page" missing and most of them are fact of missing admin
> > user. Some people just find using commandline just too difficult.
>
> > Propably it just could be simple question like:
>
> > Create default administrator user named 'admin' [default: no]?
>
> Already been doing this for over a year with our custom environment
> creation script--definitely not a bad idea to add directly to Trac.
> Just as long as it's optional (ie. we add the default administrator to
> an @administrator group, rather than give them TRAC_ADMIN directly).
same here .... to be flexible with giving full rights.

--~--~---------~--~----~------------~-------~--~----~
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: Current wiki page URL for a macro

[Trac-dev] Trac Links to files with @ (at-sign) in path

Hi,
 I post this question to the Trac User group (http://groups.google.com/
group/trac-users/browse_thread/thread/e11b28abae4ff79/
e97b512e58893e97#e97b512e58893e97), but nobody response to me.

 I have svn repository under my trac and in this repository I have a
many folders with @ (at-sign) prefix. This is very obviously if you
are programming Matlab objects. Is there any way how to use TracLinks
to files in these folders?
For example I need link to this file (without file revision):
source:/trunk/scheduling/ <at> graph/complete.m

Thank you
 Michal

--~--~---------~--~----~------------~-------~--~----~
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: Trac Links to files with @ (at-sign) in path

TIM wrote:
> For example I need link to this file (without file revision):
> source:/trunk/scheduling/ <at> graph/complete.m

Not tried this but does:

source:/trunk/scheduling/%40graph/complete.m

work?

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]

--~--~---------~--~----~------------~-------~--~----~
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: Maximum recursion depth issue in rendering templates

I searched days ago, and think we need do something to this problem,
because this can be a serious security problem in some circumstances.
Think of that someone trigger this function by adding a very long
template, the server will die siliently.

On 8月24日, 上午9时59分, "Richard Liao" <richard.lia...@gmail.com> wrote:
> Hi all.
>
> I have met a trac crash when I was trying to create new ticket or
> access admin pages.
> The trac crashes hardly with error: "segmentation fault" in my FreeBSD box.
> After some digging, I found the problem lays in genshi's transform module.
>
> The following is a test script to reproduce that hard crashe by
> setting recursion limit exceeds the platform's capabilities:
>
> import sys
> from genshi.input import HTML
> from genshi.builder import tag
> from genshi.filters.transform import Transformer
> sys.setrecursionlimit(1000 * 20)
> stream = HTML('<html><head><title>Some Title</title></head>'
>             '<body>Some <em>body</em> text.</body></html>')
> for i in xrange(1000 * 10):
>     stream = stream | Transformer('body').prepend(tag.h1('Document Title'))
> print stream.render()
>
> If comment out setrecursionlimit line to use system default recursion
> limit, it raises exception: "RuntimeError: maximum recursion depth
> exceeded".
>
> File ".../genshi/filters/transform.py", line 686, in _unmark
>   for mark, event in stream:
> File ".../genshi/filters/transform.py", line 1129, in __call__
>   for mark, event in stream:
> File ".../genshi/filters/transform.py", line 713, in __call__
>   for mark, event in stream:
> File ".../genshi/filters/transform.py", line 682, in _mark
>   for event in stream:
> File ".../genshi/core.py", line 267, in _ensure
>   event = stream.next()
> File ".../genshi/filters/transform.py", line 686, in _unmark
>   for mark, event in stream:
> File ".../genshi/filters/transform.py", line 1129, in __call__
>   for mark, event in stream:
> File ".../genshi/filters/transform.py", line 713, in __call__
>   for mark, event in stream:
> File ".../genshi/filters/transform.py", line 682, in _mark
>   for event in stream:
> File ".../genshi/core.py", line 267, in _ensure
>   event = stream.next()
> ...
>
> The problem is that the transform module is in very deep and unlimited
> recursion.
>
> I think it's a problem in genshi, maybe also in trac?
>
> I am not sure why trac crashes siliently with no exception raised
> after I searched trac source codes but can't find any lines about
> setrecursionlimit.
>
> Has anyone got the same situation?
>
> Regards,
--~--~---------~--~----~------------~-------~--~----~
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: TicketModerator plugin guidance

I think the workflow plus a ticket filter (to prevent unmoderated
"pending" tickets from being returned in a query) might work for
anonymously reported tickets; however, I don't see how to use it for
moderating ticket comments -- unless an anonymous comment moves the
whole ticket back to the pending state (not very desirable).

On Sun, 2008-08-31 at 17:32 -0700, rupert.thurner <at> gmail.com wrote:
> would the new workflow be a solution for that too?
> 
> On Aug 28, 5:11 am, John Siirola <jsiir...@gmail.com> wrote:
> > Folks,
> >
> > I have been using Trac on some internal projects for coming up on a year
> > now, and was just presented with a new project that will require a new
> > Trac plugin.  I am new to both Python and Trac internals, so I would
> > greatly appreciate any design guidance anyone might offer before I start
> > blindly wandering in the dark.
> >
> > The situation:  There is an open source project that would like to
> > switch to Trac.  We would like to support anonymous ticket creates &
> > appends.  The catch is the hosting provider is paranoid about ticket
> > butchers and content accountability.  The result is that we (by rule)
> > can not allow anonymous users to directly edit any publicly-viewable web
> > content.
> >
> > The idea: create a TicketModerator plugin that will take an incoming
> > ticket (new or comment) generated by an anonymous user and put it into a
> > "holding pen".  It will then notify (e-mail) a dev, and the dev can
> > click a link to either accept or reject the submission.
> >
> > I figure there are at least two possible ways to implement this:
> >
> > 1) route all anonymous contributions to a custom ticket state, and then
> > write a ticket filter that will always hide those tickets from the web
> > interface (i.e. queries, reports, browsing, etc).  There are a couple
> > problems, though... The hidden tickets / comments will occupy a space in
> > the database: they will consume a ticket number or comment number that
> > will show up as a hole until the record is moderated (or forever if it
> > is rejected).  Plus, while I could store new tickets with a custom
> > state, what can I do with comments (maybe a sacrificial ticket to hold
> > all pending comments???)?
> >
> > 2) Create new "pending" tables in the database that mirror the ticket,
> > ticket_change, and ticket_custom schema.  Then attach to something
> > (ITicketManipulator or ITicketChangeListener?) to redirect incoming
> > anonymous submissions to the pending tables.  Separate code (attached to
> > an IRequestHandler?) can handle the moderator's decision and either
> > purge the record from the pen or move it into the real tables.  For
> > this, what is the process to make sure that the pending tables match the
> > corresponding main table schemas?  Can I really redirect the ticket
> > storage location through the existing extension points?
> >
> > For the record, I have already gone over wiki/TracDev/PluginDevelopment,
> > ComponentArchitecture (several times), and am starting to dig (randomly)
> > through projects on trac-hacks.
> >
> > Thoughts and suggestions are greatly appreciated...
> >
> > Thanks,
> > john
> > 

--~--~---------~--~----~------------~-------~--~----~
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: Maximum recursion depth issue in rendering templates

Richard Liao wrote:
> I searched days ago, and think we need do something to this problem,
> because this can be a serious security problem in some circumstances.
> Think of that someone trigger this function by adding a very long
> template, the server will die siliently.
>

Don't throw around the term "security issue" unless you can back it up.
This is at worst an annoyance, however I don't know of any way to
exploit it remotely or do anything worse than DoS the server should the
admin leave a broken page up.

This is also not a Trac issue, it is a design problem in Genshi. The
simple solution is stop nesting filters so deeply.

--Noah

[Trac-dev] Re: Request match "precision" in match_request()

On 01.09.2008, at 01:35, Remy Blank wrote:
> While working on #4878 (Weird URL handling of additional characters  
> on the end), which asks that requests to e.g. "/timeline/bogus"  
> either return a 404 or a permanent redirect to "/timeline", I've  
> been looking at match patterns in match_request(). This has raised a  
> few questions for which I would like to get some feedback:
>
> * Currently, many request handlers match very liberally. For  
> example, any request that matches "/admin.*" will be handled by the  
> admin module, including "/adminlskjdfkljsd". Is this intentional? If  
> not, shouldn't this be fixed?

Not intentional AFAIK, should be fixed.

> * Many handlers allow a trailing /, for example "/newticket" and "/ 
> newticket/". What is the reason for this? Noah has mentioned this  
> being a convenience for people entering URLs that don't know what  
> they are doing. Are there any other reasons?

The problem here is that if you don't allow a trailing slash, you  
should at least automatically redirect from e.g. /foo/ to /foo (most  
of the web does this the other way around, but hey).

So if we get more strict here, we need to add some kinda of slash- 
stripping redirector thing.

> * The "matching precision" is very variable between handlers. Some  
> handlers match only precise URLs (e.g. "/tickets/([0-9]+)$"), others  
> are more graceful (e.g. "/report(?:/([0-9]+))?", which will show the  
> list of available reports for "/report/bogus").
>
> Is there a rule for how precise a match_request() should be? I see  
> two possibilities:
>
> * Be strict in what a handler accepts. This has the advantage of  
> giving a more precise answer for malformed URLs (usually a "No  
> handler matched request to ..."). But it is less forgiving for user- 
> entered URLs, and might therefore have usability issues. If this  
> option should be followed, then a trailing / should probably not be  
> accepted.
>
> * Be forgiving, and return a reasonable result for any URL matching  
> at least the handler's root component. For example, in the case of  
> the timeline, show the timeline for any request matching "/ 
> timeline/.*". The advantage is that users are less likely to be  
> shown an error message. But this is technically less correct.
>
> Opinions? Which rule should I follow?

I very much prefer strict. The rule should be not to expose the same  
resource/representation under multiple different URIs. So even if  
there are valid convenience features such as allowing both /foo/ and / 
foo, one needs to redirect (as in 301) to the other.

One issue here is that changes in this space may break URIs out there  
on the web (bookmarks, search indices, links etc). That's something we  
need to be very careful about: we're not just "breaking" the Trac  
site, but the sites of all the Trac users out there. :P

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
-~----------~----~----~----~------~----~------~--~---