Fix broken edit/delete buttons on some occasions.

[josephalvis]

This issue is described in: Used to work - can no longer add edit short urls - nothing changed #2102

At least one cause of this can be if a reverse proxy (e.g. cloudflared tunnel) sends an "id" parameter on every request, the nonce verification for the edit and delete buttons breaks.

This change is to rename the parameter to "elid" to prevent it conflicting with the "id" param. This resolves the issue and the buttons work again.

[ozh]

Not sure I get it. Do you mean that each and every web application using id as a REQUEST parameter is broken by Cloudflared Tunnel because they overwrite the value ? If so, there has to be a configuration setting somewhere to avoid this and adapt the tunnel to the app instead of the other way round.

This is a slippery road I'm relunctant to get into : patch bits of YOURLS here and there, not to fix things, but to make sure it works with other tools.

[josephalvis]

Not sure I get it. Do you mean that each and every web application using id as a REQUEST parameter is broken by Cloudflared Tunnel because they overwrite the value ? If so, there has to be a configuration setting somewhere to avoid this and adapt the tunnel to the app instead of the other way round.

I identified the wrong culprit. This had nothing to do with cloudflared.

It looks like the issue I was having was caused by sharing a domain between yourls and a synology NAS. The Synology webui was accessed as nas.example.com and yourls as test.example.com for instance. Synology sets a cookie "id" which gets shared and clashes with the id used by yourls because $_REQUEST['id'] includes $_COOKIE['id'].

What would you think about excluding cookies when looking up 'id'? I'm no longer using the same domain for yourls and the NAS but it seems like it could happen again to someone else.

[ozh]

The Synology webui was accessed as nas.example.com and yourls as test.example.com for instance

I think this is the really problem here. A cookie set on nas.example.com should not be readable from test.example.com and vice versa -- at least cookies set on yourls1.example.com and yourls2.example.com should not be readable from an other YOURLS instance than the one it was created by.

Back to you suggestion, yes we could exclude cookies here, I was using $_REQUEST to handle either $_GET or $_POST (and we need this) but didn't think $_COOKIES could ever be problematic. How do you suggest we do this ? $_REQUEST is used probably hundreds of times in YOURLS and I don't want to create more side effects than potential problem maybe solved.