Bug 1012527 - set the JSESSIONID cookie and header when the authentication is successful even when the subsequent query results in error
set the JSESSIONID cookie and header when the authentication is successful ev...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi (Show other bugs)
3.3.0
Unspecified Unspecified
unspecified Severity low
: ---
: 3.3.0
Assigned To: Michael Pasternak
Elena
infra
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-26 11:14 EDT by David Jaša
Modified: 2016-02-10 14:18 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-29 07:01:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Jaša 2013-09-26 11:14:04 EDT
Description of problem:
Authentication errors should be evaluated prior to any other kinds of errors and the resulting behaviour WRT authentication information should not be influenced by subsequent error at all. In practice, that means that when user authenticates successfully with "prefer: persistent-auth" set, he should be given JSESSIONID cookie && header no matter how the rest of the query ends up.

The desired behaviour improves UX of REST API apps (it saves roundtrips and for bad

Version-Release number of selected component (if applicable):
is16 / rhevm-restapi-3.3.0-0.22.master.el6ev.noarch

How reproducible:
always

Steps to Reproduce:
1. perform a query like this with valid credentials:
curl <...> -u user@domain.example.org https://rhevm.example.org/api/nonsense
2.
3.

Actual results:
JSESSIONID cookie and headers are not sent

Expected results:
JSESSIONID cookie and header are sent

Additional info:
the example doesn't make much functional sense but it's a good reproducer. I'd expect the real use case for combination of timeout (--> need to relogin) and change of something between app refreshes
Comment 1 Michael Pasternak 2013-09-29 07:01:51 EDT
i disagree (In reply to David Jaša from comment #0)
> Description of problem:
> Authentication errors should be evaluated prior to any other kinds of errors
> and the resulting behaviour WRT authentication information should not be
> influenced by subsequent error at all. In practice, that means that when
> user authenticates successfully with "prefer: persistent-auth" set, he
> should be given JSESSIONID cookie && header no matter how the rest of the
> query ends up.

this is not correct, since our api uses ROA architecture, every resource
is considered a entry point to api (unlike in SOA where you have single entry
point where authenticate takes place), so you should see this as accessing
incorrect address (url) in the NET.

Note You need to log in before you can comment on or make changes to this bug.