Re: Spam attack, observations, how to repair

On Fri, Jul 04, 2014 at 09:08:19PM -0400, John P. Rouillard wrote:
> 
> the form item_designator/foo is always handled using:
> 
>   5) if the path starts with an item designator and is longer than one
>      entry (as in example 5, “file1/kitten.png”), then we’re assumed to
>      be handling an item of a FileClass, and the extra path information
>      gives the filename that the client is going to label the download
>      with (i.e. “file1/kitten.png” is nicer to download than
>      “file1”). This raises a SendFile exception.
> 
> which seems wrong. It should only raise a SendFile if the class
> (klass) for the designator matches:
> 
>    isinstance(klass, hyperdb.FileClass):

Yes, this additional check should be added.
Probably the idea is that something like a FileClass can be added in
customizations without deriving from FileClass. But I've done heavy
customizations and never needed something like this for now.

> But this explains why we get a 404 returned for .../user5/ as there is
> no file object to send at user5.
> 
> I think this diff goes part way to fixing this issue:
> 
> +            if len(path) > 1:
> +                if isinstance(klass, hyperdb.FileClass):
> +                    # send the file identified by the designator in path[0]
> +                    raise SendFile(path[0])
> +                else:
> +                    self.add_error_message("HINT: try removing a trailing path from %s"%"/".join(path))
> +                    raise NotFound("HINT: try removing a trailing path from %s"%"/".join(path))
> +

Yes, looks reasonable.
We should probably add a test for this (and for the html content-type
rewriting)...

> The 404 that is raised by NotFound("HINT...") uses the
> tracker_home/html/_generic.404.html template which doesn't display the
> text of the raised NotFound error. Nor does it display the error
> message added by add_error_message.

[...]

> So I am not quite sure what's the right thing to do here. I do have a
> replacement _generic.404.html that will display the argument to
> add_error_message, but it seems the value passed to the exception
> class when the exception is raised should be used somehow.

Yes, that would be nice. But I think we can live with a generic error
message if this is too much work.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]
allmenda.com member                     email: [email protected]

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Roundup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/roundup-users