Resource alerts settings ("My Alerts") will not save changes while logged in.
Fastburn opened this issue · 9 comments
Summary
Expected behavior
Update MyAlerts list, click save, list is saved.
Actual Behavior
Receive error alert, and MyAlert changes are not saved. (Error: must be logged in to update alerts)
Steps to reproduce
Sign in and navigate to [My Alerts](https://galaxyharvester.net/myAlerts.py?)
Set some alerts for Group resources (e.g. mineral)
Save/update your settings
Reload the page
OS/Browser Context
OS: Windows 10
Browser: Firefox (latest) & Chrome (latest)
Thanks for the report, @Fastburn. Unfortunately, I've not been able to reproduce this on the production site (or my local dev) in either browser on Windows 11. I also tried in Chrome and Safari on MacOS.
Is there anything else that seems off anywhere else?
To dig in a bit deeper, which protocol is being used (e.g. http vs https)? Is www. prefixed to the domain or not? Does the behavior change if you modify any of this?
I have asked another often regular user of the website, Jaws, who hasn't seen this either. I have tried it via HTTP and HTTPS with the www. prefixed on the domain, and it didn't change anything same issue. This has been an issue for more than a month, but it wasn't always acting like this, as you can see I have some saved from the past.
I have asked another often regular user of the website, Jaws, who hasn't seen this either. I have tried it via HTTP and HTTPS with the www. prefixed on the domain, and it didn't change anything same issue. This has been an issue for more than a month, but it wasn't always acting like this, as you can see I have some saved from the past.
Thanks for the additional context, @Fastburn. That sounds frustrating.
The error message "Error: must be logged in to update alerts" can occur if a user isn't signed in and attempts to do one of the following:
- request a list of existing saved alerts (GET)
- create a new alert / update existing alerts (POST)
Both of these actions, as far as I can tell, use the exact same logic for determining if a user is signed in. Given you're able to retrieve your list of alerts, it appears the first example (GET) works for you, but the second one (POST) doesn't.
This is strange. The only obvious difference to me is the HTTP method being used in the request (GET vs POST). The first thing that jumps out at me is perhaps an overly-aggressive browser plugin or browser protection via antivirus/anti-malware software that is specifically triggering when a POST request is made instead of a GET request.
Have you recently made any changes to your browser protection?
EDIT
I want to highlight that these requests are made asynchronously, which might also be a factor at play. I assume you can make regular synchronous POST requests, e.g. signing in. Asynchronous POST requests (such a submitting alert updates) might be the culprit.
Nothing has changed, no new plugins. I have tried different browsers one of which has no extensions installed and the issue is the same for me.
@Fastburn Gotcha. I'd like to know if the POST and GET requests are actually doing something different.
To do this, I'll need you to:
- enable and open the developer tools in your browser
- switch to the Network tab
- filter XHR traffic
- go through the process of refreshing the page and then attempt to update the alerts.
You should see requests for the following resources requested:
getResourceGroupList.py(GET)updateFilters.py(POST)
You should be able to click on each request. For each request, there should be a cookie with the key gh_sid, and the value should be the same in both requests.
DO NOT SHARE the value here. 😅 But, I'm curious...
- Is there a
gh_sidcookie in both requests? - If so, is the
gh_sidvalue the exact same in both requests?
Again, please do not share the value of the cookie here.
1.) gh_sid is in both both requests.
2.) gh_sid value is the same for getResourceGroupList.py (GET) and updateFilters.py (POST)
The only odd thing that stood out was that for the POST, it was under https://www.galaxyharvester.net/updateFilters.py?undefined=
@Fastburn I'm kinda mystified on this one too, but I cleaned up a couple things on that form that was causing it to pass that extra undefined. I also cleaned up some old session data. I can't see any direct link between these things and this issue, but if it changes anything, it might give us a clue. If you could do a hard refresh and test again, please let us know if anything changes.
This seems to have fixed it. Thank you guys for looking into it, I know it was a pain.
sweet