What about using mod_rewrite to map the old url into a GET variable?
On Oct 28, 3:19 pm, Timothy Farrell <[EMAIL PROTECTED]> wrote:
> Here's the deal. Currently apache does serve these files directly, but
> that is part of the problem (security).
> We have some old PDF code that generates reports and slaps them in a
> network folder. Due to several design flaws, this old PDF-generation
> system must go the way of the Dodo. Before I replace it wholesale, I'd
> like to put web2py in the middle of it. My web2py app works like this:
> 1) receive request for a particular file
> 2) Generate equivalent PDF with new generation system (Pisa/ReportLabs)
> 3) Compare page lengths and file sizes
> 4) If page lengths are equal, and sizes are similar, serve the new one
> otherwise serve the old one.
>
> This is an interim step to completely replacing the old system. The
> problem is that I can't access the piece of code that generates the
> hyperlinks. So I have to make web2py morph to accept the old style.
>
> -tim
>
> mdipierro wrote:
> > Is this because of static files for a specific app?
>
> > why not have apache serve them directly?
>
> > I cannot imagine any other case when this is relevant. Can you give us
> > an example?
>
> > Massimo
>
> > On Oct 28, 2:40 pm, Timothy Farrell <[EMAIL PROTECTED]> wrote:
>
> >> I understand your position. Under normal circumstances, I would agree
> >> with you. But, I just have a situation where I can't control exactly
> >> what's coming in and so I need web2py be more lenient. I'll (have to)
> >> run a custom version of web2py until I no longer need to interface with
> >> this older system (which is likely to be about a year).
>
> >> -tim
>
> >> mdipierro wrote:
>
> >>> I disagree. The web2py url is only used inside web2py and I think
> >>> web2py should enforce good practice even if it is more strict than
> >>> actual specs. We can disagree on what is good practice. For me is when
> >>> the url only includes alphanumeric characters, _ , /, and non
> >>> consecutive dots. This avoid potential trouble with for example
> >>> directory traversal attacks in downloading files.
>
> >>> Massimo
>
> >>> On Oct 28, 2:13 pm, Timothy Farrell <[EMAIL PROTECTED]> wrote:
>
> >>>> Thanks Kyle.
>
> >>>> What I have to say below may be heresy...
>
> >>>> In light of the silence on this subject, I've decided that web2py's URL
> >>>> validation (for the purposes of mapping URLs to
> >>>> applications/controllers/functions) oversteps its bounds and
> >>>> over-zealously restricts (at least for my own purposes). I've come to
> >>>> the opinion that web2py should only validate the portions of the URL
> >>>> that it needs to parse in order to run the appropriate function and pass
> >>>> the appropriate args. All other input sanitization should be left to
> >>>> the relevant application functions.
>
> >>>> Regarding RFC1738, as I mentioned below, this is meaningless because the
> >>>> wsgiserver already unquotes the path before it passes it on to web2py.
>
> >>>> In the practical sense, this means that web2py should only validate the
> >>>> first three elements of the path and leave the rest to the application.
> >>>> This also leaves an implementation problem with regular expressions, but
> >>>> that's another story.
>
> >>>> Opinions? Thoughts? Tomatoes?
>
> >>>> Kyle Smith wrote:
>
> >>>>> You are absolutely correct that it's not the same discussion. I was
> >>>>> just trying to point you to previous conversation about url validation
> >>>>> in general since it is a similar topic.
>
> >>>>> Kyle
>
> >>>>> On Wed, Oct 22, 2008 at 1:50 PM, Timothy Farrell <[EMAIL PROTECTED]
> >>>>> <mailto:[EMAIL PROTECTED]>> wrote:
>
> >>>>> Thanks for your input, but this is not about the IS_URL
> >>>>> validator. This is about web2py utterly rejecting any request
> >>>>> that has and apostrophe (or other RFC-valid punctuation) in the
> >>>>> middle of the path.
>
> >>>>> -tim
>
> >>>>> Kyle Smith wrote:
>
> >>>>>> A similar discussion happened shortly after I started using
> >>>>>> web2py. If you read through this thread you can see the
> >>>>>> discussion that Massimo and I had on the topic. You probably want
> >>>>>> to jump down to around message 13 in the thread.
>
> >>>>>>
> >>>>>> http://groups.google.com/group/web2py/browse_frm/thread/414723e11c9f9...
> >>>>>>
> >>>>>> <http://groups.google.com/group/web2py/browse_frm/thread/414723e11c9f9...>
>
> >>>>>> I currently use my own validator (also not completely RFC1738
> >>>>>> compliant) for parsing urls instead of the built in IS_URL.
>
> >>>>>> Kyle
>
> >>>>>> On Wed, Oct 22, 2008 at 1:21 PM, Timothy Farrell
> >>>>>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>
> >>>>>> Ugh, I have an issue.
>
> >>>>>> It has come to my attention that the URL validation does not
> >>>>>> conform to RFC1738 (section 2.2 is the most relevant). This
> >>>>>> is fine for the schema://host/application/controller/function
> >>>>>> part of the URL, but it causes problems in such circumstances
> >>>>>> that I ran into today. Here are the details:
>
> >>>>>> I made a PDF file pass-through that I access like :
> >>>>>> /init/default/pdfpass/dir/PDF_FILENAME.pdf
>
> >>>>>> I ran into the problem of sometimes a request comes in that
> >>>>>> looks like: /init/default/pdfpass/dir/PDF'FILENAME.pdf
> >>>>>> (notice the apostrophe)
>
> >>>>>> This doesn't play well with the URL validation regexp from
> >>>>>> main.py line 39. I would like to be able to use normal URL
> >>>>>> characters in my function arguments.
>
> >>>>>> For those with not enough time/patience to read an RFC,
> >>>>>> normal path characters are: letters, numbers, and *$ - _ . +
> >>>>>> ! * ' ( ) ,* This does not include the special URL path
> >>>>>> characters: */ @ ? : = & ;*
>
> >>>>>> Thoughts? Can we include these characters without
> >>>>>> compromising security?
>
> >>>> tfarrell.vcf
> >>>> < 1KViewDownload
>
> >> tfarrell.vcf
> >> < 1KViewDownload
>
>
>
> tfarrell.vcf
> < 1KViewDownload
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
