Ticket #1017 (closed Defect: fixed)

Opened 5 years ago

Last modified 5 years ago

Webclient start fails if stale cookies are present

Reported by: jri Owned by: jri
Priority: Major Milestone: Release 4.8.4
Component: DeepaMehta Standard Distribution Version: 4.8.2
Keywords: Cc: dgf, Malte, JuergeN
Complexity: 3 Area:
Module: deepamehta-topicmaps

Description

This happens when at the same URL another DM instance is present meanwhile (e.g. when you reset the DM database).
Workaround: delete the dm4_topicmap_id and dm4_workspace_id browser cookies, or restart the browser.

The problem exists since DM 4.8.2 in conjunction with #994, see ticket:994#comment:12.

Change History

comment:1 Changed 5 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 5 years ago by Jörg Richter <jri@…>

comment:3 Changed 5 years ago by Jörg Richter <jri@…>

In 34abd51c2cd53ad76a0a80828542c7765296de3d/deepamehta:

Webclient start: topicmap ID validity (#1017).

On Webclient start the ID of the topicmap initially shown is cheked for validity.
The initial topicmap ID is obtained from two sources (in this order):

  • The browser URL path (/topicmap/<id>/topic/<id>)
  • From the dm4_topicmap_id browser cookie

If both IDs are not present resp. not valid, the ID is obtained from the 1st item of the Topicmap menu as a fallback.

An ID is regarded valid if all applies:

  • The object exists in the DB and is actually a topic (not an assoc)
  • The topic is READable by the current user
  • The topic is actually a Topicmap (not a Note or something else)

So, the Webclient starts properly even if another DB is present meanwhile, e.g. after a DB reset.
The stale browser cookie is fixed.

See #1017.

comment:4 Changed 5 years ago by Jörg Richter <jri@…>

In 0986df3d79978c790d9bd51b556216962f824a0f/deepamehta:

Webclient: fix topicmap initialization (#1017).

There was another intricate edge case: the Topicmaps plugin might regard an ID as valid topicmap ID although it is not. This happens if a stale Topicmap topic is obtained from the browser cache. This happens if the GET request's condition (If-Modified-Since) is not satisfied and the response is 304 Not Modified. For this to happen it is sufficient if the pretended topicmap ID (e.g. from a stale cookie) refers to *some* existing DB object (topic or association!) whose modification timestamp is "old enough"! This case is not detectable by the Topicmaps plugin at init(1) stage and will only be detected by the Workspaces plugin (at init(2) stage). The Topicmaps plugin will finally obtain a valid topicmap ID through a fallback at init(3) stage.

See #1017.

comment:5 Changed 5 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to fixed

comment:6 Changed 5 years ago by jri

See also #1058

Note: See TracTickets for help on using tickets.