Opened on 10/26/2017 at 02:08:26 PM
Closed on 10/26/2017 at 02:43:18 PM
Last modified on 10/26/2017 at 02:46:49 PM
#5944 closed change (fixed)
Introduce sitescripts.reports.web.resolveReport handler
| Reported by: | matze | Assignee: | kvas |
|---|---|---|---|
| Priority: | P3 | Milestone: | |
| Module: | Sitescripts | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Platform: | Unknown / Cross platform | |
| Ready: | yes | Confidential: | no |
| Tester: | Unknown | Verified working: | no |
| Review URL(s): | |||
Description
... to accept encrypted guid values, decrypt them, and redirect to the volatile, original report, if still available, e.g.
GET /resolveReport/nQLtNSgZDgffX2C7,Qn4UyBEVZQqUnxj8mTiviOkyHSezUJNN/X7O2zfx9/TDWbYSistlhACGNd3m1ScdERLJQg== HTTP/1.1 Host: reports.adblockplus.org
HTTP/1.1 302 FOUND Location: https://reports.adblockplus.org/digest/b418ffa6-xxxx-xxxx-xxxx-xxxxxxxxxxxx
The idea is to implement this logic as a WSGI handler (analogous to the other ones in []sitescripts.reports.web) and apply access-control in the surrounding HTTPd layer, so that between the above request and response example there would be an HTTP auth challenge (via HTTPS) when redirecting for the first time in the current browser session.
This should allow for i.e. data dashboards to link to the original data records despite their anonymization, whilst also providing sufficient access control.
Attachments (0)
Change History (3)
comment:1 Changed on 10/26/2017 at 02:42:34 PM by abpbot
comment:2 Changed on 10/26/2017 at 02:43:18 PM by kvas
- Resolution set to fixed
- Status changed from new to closed
comment:3 Changed on 10/26/2017 at 02:46:49 PM by trev
For reference, the correct URL would be https://reports.adblockplus.org/b418ffa6-xxxx-xxxx-xxxx-xxxxxxxxxxxx - this is not a digest.
A commit referencing this issue has landed:
Fixes 5944 - Introduce sitescripts.reports.web.resolveReport handler