Re: CVE details page
От | Jonathan S. Katz |
---|---|
Тема | Re: CVE details page |
Дата | |
Msg-id | 4285DCDA-B04F-464F-9A44-67F75448024D@postgresql.org обсуждение исходный текст |
Ответ на | Re: CVE details page (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: CVE details page
|
Список | pgsql-www |
> On Mar 28, 2021, at 7:26 AM, Magnus Hagander <magnus@hagander.net> wrote: > > On Sat, Mar 27, 2021 at 8:35 PM Jonathan S. Katz <jkatz@postgresql.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@postgresql.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. Unless you really think this is a blocker, I’d like to get this merged so I can start backfilling the data, which will take a hot minute to do. Thanks, Jonathan
В списке pgsql-www по дате отправления: