iSpot uses a cookie to remember your login - if the cookie is somehow getting corrupted iSpot might think you’re not properly logged in. If you are able, can you clear all cookies on the ispotnature.org domain, close the browser, open it again and log in again?
On Friday, I had to roll the code back to the beginning of last week because a change I made (to hide the + Add Observation button while you’re actually adding an observation) didn’t work properly and actually hid the button under other conditions. My only thought is that suppressing that button had a knock-on effect on other forms. That change is no longer in the live code.
09:16
Goodness, that was my idea…forget it.
Still cannot open links from my tracker this morning.
BUT I can open all recent Observations from the Home page.
You would have thought it would be easy: “if there is a form, don’t show the button” - but the search form is probably tripping it up as that’s there on the home page all the time!
Opening dictionary entries from the forum
in same tab - 404s
in new tab - 404s
in new window - 404s
in new private window - works
Opening them from an observation when logged in
in same tab - works
in new tab - 404s
in new window - 404s
in new private window - works
Yes (thanks), I concur - must be pretty hopeless for Phone users!
Obviously 404 means not found (whereas 403 means denied) which suggests to me the URL that’s being embedded in the forum post is being corrupted. Have you got any specific examples please? I want to see that actual forum post that’s leading to this issue.
Failed link (from Dictionary anomalies)
Working link (from same place, open in new private window)
The two links look identical to my eye (and I would expect them to be, as one wouldn’t expect all browsers to suddenly start corrupting links in the same contexts).
The symptom is that the same links either do or don’t work depending on whether they are opened in same tab, new tab, new window, or new private window. The pages get well drawn before being overwritten by 403/404 error declarations. A hypothesis would be that the scripts are failing to obtain a connection to the relevant database. Presuming that the same database software is being used for both the observations and dictionary the different error codes suggest that they error codes are being generated by either server or client side scripts, most likely the former, rather than by the underlying database or server software.
Interesting (thanks) my original link opens when not logged in, or in an Incognito (“new private windowt”) tab
For those using phone technology a real mystery
I can sort of expect that opening a link into an Incognito window might lead to 403 Unauthorised issues as an Incognito window is not supposed to store any personal information - so the cookie that would otherwise keep you logged in between browser tabs would not work.
Except - incognito/private windows are one of the circumstances in which it works correctly.
Just looking at an observation isn’t supposed to have any access restrictions. Either server threads are running the incorrect credentials/permissions and running in OS-level security controls, or inappropriate security checks are being performed somewhere, or an inappropriate response code has been selected and the actual failure is something else, or …
The different error codes (403 vs 404) between observations and dictionary entries should be telling us something.
One thing that hasn’t been tried yet is opening an observation, project or user profile, in various ways, from the forum.
Tries it out
Opening observation from forum
in same window - 403s
in new tab - 403s
in new window - 403s
in new private window - works
Opening full size images (automatically in a new tab) works, so there must be a difference in how access to observations and access to images is handled.
Yes, the only way I can interact properly from my Tracker (in most cases) is to open in a private incognito window to view and then IF a response is required to Log in…
I seem to have to do that for all except my own Observations
An attempted summary (I haven’t exhaustively tested behaviour when not logged in)
You can open an observation, project or user profile if it is 1) yours 2) you’re not logged in or 3) you’re opening it in the current tab. All of these are public, so there is no reason why a 403 forbidden should be produced. But all these display differently depending on whether they’re yours or someone else’s - you can edit your own observations, projects and profile, and fewer tabs are displayed when looking at someone else’s profile, so it is necessary to look at the cookie to see who you are. The observed behaviour could be explained by the system looking and generating a 403 instead of or in addition to limiting what is displayed, or by attempting to deliver the bits of the page that aren’t supposed to be generated.
Dictionary entries behave sufficiently differently that the connection isn’t obvious. You can open them only if you’re not logged in, and the error code is a 404.
Based on the above analysis I tried a hypothetical workround for the changes tracker - use the right click menu to copy the link, and then paste it into the address bar in the same tab. But it doesn’t work, generating a 403 forbidden instead.
This suggests that the referring page information in the HTML request is having an effect on how iSpot’s servers are handling the request.
Can you please show me what the URL is that doesn’t work? Even if you have to leave off the https at the beginning so I can see exactly what page its trying to go to?
Are you unable to replicate the problems? If so, are you working with administrator/curator privileges?
(Leaving off the https doesn’t work - the forum software puts it back.)
As expected, the link works fine for me - even if I log out. Its nothing to do with privileges because viewing an observation record does not require the user to be logged in.
Have you cleared all ispotnture.org cookies? Certainly worth doing that.
13:55
The marsh ragwort link generates 403 - Forbidden for me
It generates Marsh ragwort | Observation | UK and Ireland | iSpot Nature
https://www.ispotnature.org/communities/uk-and-ireland/view/observation/846741/
I removed the suffix so you can see it is correct.
.
Why are so few people reporting errors and why has no-one posted an Ob since 10:30 today?
Why are lavateraguy and I the only ones having trouble today?
Something just occurred to me: if you take the title text off the end of an Observation URL, you must not take off the final slash - otherwise you will get a 404. If the process of pasting links into forum posts is somehow losing that final slash, you’ll end up with non-working links. But they won’t work for anyone - it won’t be selective as to who clicks the link.