Ticket #795 (closed Defect: fixed)

Opened 7 years ago

Last modified 7 years ago

Changing passwords is broken in DM 4.6

Reported by: jri Owned by: jri
Priority: Critical Milestone: Release 4.7
Component: DeepaMehta Standard Distribution Version: 4.6
Keywords: Cc: dgf, Malte, JuergeN
Complexity: 3 Area:
Module: deepamehta-accesscontrol

Description (last modified by jri) (diff)

The new password is stored in plain text. The SHA256 encoding is missing. So a subsequent login fails. The account is broken!

Creating a new user account and setting a password from the start works. But changing it afterwards breaks the account.

Thank you very much, Arjun, for reporting!

Change History

comment:1 Changed 7 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 7 years ago by jri

  • Description modified (diff)

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

In 1622a50872eacd4708426327bf80ac230150dd27/deepamehta:

Changing passwords work again (#795).

Background: since DM 4.6 the REST API and declarative migrations support a simplified format for create/update requests. The child topic's type_uri must no longer be specified as it is redundant (see #636). The type_uri field is initialized by the server automatically.

The DM 4.6 Webclient made use of the simplified format and did not initialze the topic's type_uri in update requests. This broke the working of plugins which register a listener for the client-side pre_update_topic event as most plugins do work based on the topic's type there.

The Access Control plugin uses the pre_update_topic listener to encode a changed password at client-side before it is send to the server.

Now with this fix the topic/assoc passed to the pre_update_topic/pre_update_association listeners is again guaranteed to have its type_uri field initialized.

See #795.

comment:4 Changed 7 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.