LP notification parameters make URLs skanky
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Fix Released
|
Medium
|
Stuart Bishop | ||
Bug Description
I file a bug against Launchpad, and Malone helpfully redirects me to the page of the new bug. However, the '?lpnotificatio
One way of fixing this:
We should store notification data on the server in the form (sessionID, URL, notification). For each request, we check whether the user's session ID and the request's URL correspond to a notification entry, and if they do:
- We make the TAL for the notifications area return the notification
- We delete the notification from the database
Example:
When I submit a new bug in Malone:
- Malone adds a new notification entry with (user's session ID, new bug's URL, "Thank you for your bug report.")
- Malone redirects me to the new bug's URL
- When my browser requests the new bug's URL, the notification is matched to my session and gets displayed
Voilà, no skankiness.
| Stuart Bishop (stub) wrote | #1 |
| Changed in launchpad: | |
| assignee: | nobody → stub |
| status: | New → Accepted |
| Changed in launchpad: | |
| status: | Accepted → Fixed |
The current implementation is correct. All alternative implementations introduce race conditions, either on the client or server, or are unreliable.
For example, the suggested implementation above fails when there are multiple windows open being used against Launchpad at the same time. Also, We can't rely on knowing what the previous page was when checking for notifications, as this information is not always available.
It looks like we need to break the existing implementation to improve the aesthetics. Hopefully the race conditions will occur infrequently enough that people will not notice.