Re: CVE details page

On 3/28/21 10:01 AM, Jonathan S. Katz wrote:
> On 3/28/21 9:44 AM, Jonathan S. Katz wrote:
>>
>>
>>> On Mar 28, 2021, at 7:26 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>
>>> On Sat, Mar 27, 2021 at 8:35 PM Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>>>>
>>>>> On 3/25/21 8:20 AM, Magnus Hagander wrote:
>>>>> On Wed, Mar 24, 2021 at 8:57 PM Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>>>>>>
>>>>>> I've modified the URL matching to be all uppercase, but keeping our
>>>>>> matching logic case insensitive.
>>>>>
>>>>> I do still prefer lowercase, but not enough to insist on it :)
>>>>>
>>>>> But do consider the redirect, that might help some ppl.
>>>>
>>>> OK, so I did:
>>>>
>>>> - matching cve/CVE
>>>> - added a redirect to rewrite to CVE
>>>
>>> Wouldn't:
>>> + if request.path.find('cve') != -1:
>>> + return redirect('/support/security/CVE-{}/'.format(cve),
>>> permanent=True)
>>>
>>> you captured the "cve" vs "CVE" part already in urls.py as a separate
>>> parameter? And then just "if blah != 'CVE' return redirect"?
>>>
>>> Either works, but looking for cve anywhere in the URL seems to set up
>>> for a future bug should we ever for example want to move the cve's
>>> into a subdir..
>>
>> We don’t capture the “cve” string in a variable and I think it’s a bit overkill
>> to do so. We only capture the numbers.
>>
>> And if we made that move to a subdir, we’d have to update the URL
>> pattern anyway, so this seems to be a bit of prefactoring.
>>
>> So I’m disinclined to change it.
>
> Looking at it more closely, I do see how it's "one step away" from
> capturing the string value. I do think it's a bit overkill given the
> vast majority of traffic will be to the uppercase, but I'm now a bit
> more open-minded to applying your suggestion and calling it complete.

And here is patch 0003 with that change.

I'll apply in a bit and start backfilling the data.

Thanks!

Jonathan