Bug 33503 - 401 status error is not correctly interpreted to open the login dialogue
401 status error is not correctly interpreted to open the login dialogue
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - Software update
UCS 3.2
Other Linux
: P1 normal (vote)
: UCS 3.1-1-errata
Assigned To: Dirk Wiesenthal
Sönke Schwardt-Krummrich
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-21 11:47 CET by Alexander Kläser
Modified: 2013-11-28 16:00 CET (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Usability
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kläser univentionstaff 2013-11-21 11:47:58 CET
+++ This bug was initially created as a clone of Bug #33443 +++

Currently, the updater module does not handle 401 (=unauthorized) errors correctly, therefore the login dialogue is not opened if the UMC server is restarted in the update process.

The problem is in the method umc/modules/updater:handleQueryError(). The handling is not correct:

> handleQueryError: function(subject, data) {
>     ...
>     if (data.status == 401) { ... }
>     ...
> }

At this point "data" has the following structure:

> {
>   "stack": "...",
>   "message": "Unable to load /umcp/command/updater/installer/status status: 401",
>   "response": {
>     "url": "/umcp/command/updater/installer/status",
>     "options": {
>       "method": "POST",
>       "data": "{\"options\":{\"job\":\"distupgrade\"}}",
>       "handleAs": "json",
>       "headers": {
>         "Content-Type": "application/json"
>       }
>     },
>     "xhr": {
>       "statusText": "Unauthorized",
>       "status": 401,
>       "response": "{\"status\": 401, \"message\": \"None\"}",
>       "responseType": "",
>       "responseXML": null,
>       "responseText": "{\"status\": 401, \"message\": \"None\"}",
>       "upload": {
>         "onprogress": null,
>         "onloadstart": null,
>         "onloadend": null,
>         "onload": null,
>         "onerror": null,
>         "onabort": null
>       },
>       "withCredentials": false,
>       "readyState": 4,
>       "timeout": 0,
>       "onreadystatechange": null,
>       "ontimeout": null,
>       "onprogress": null,
>       "onloadstart": null,
>       "onloadend": null,
>       "onload": null,
>       "onerror": null,
>       "onabort": null
>     },
>     "loaded": 34,
>     "total": 34,
>     "status": 401,
>     "text": "{\"status\": 401, \"message\": \"None\"}",
>     "data": {
>       "status": 401,
>       "message": "None"
>     }
>   }
> }

Correct would be data.response.status == 401. However, even more correct would be to use the UMC wide error handling.
Comment 1 Dirk Wiesenthal univentionstaff 2013-11-22 14:50:37 CET
Fixed in
  univention-updater 8.0.78-8.1237.201311211757

YAML updated, no changelog required (3.2-0 already released)
Comment 2 Sönke Schwardt-Krummrich univentionstaff 2013-11-27 17:03:06 CET
OK: source code change 3.1-1
OK: functionality 3.1-1
    After the update to UCS 3.2 a login dialog is shown below a UMC refresh (F5) 
    question. The login dialog contained no login buttons (due to the changed 
    hash) but a login is possible if Enter is pressed. Prior to that the user 
    must have denied the UMC refresh, otherwise the login dialog is unreachable.
OK: package build/package version
OK: YAML
Comment 3 Janek Walkenhorst univentionstaff 2013-11-28 16:00:51 CET
http://errata.univention.de/ucs/3.1/196.html