Bug 684350 - GET requests with Basic Auth has side effects
Summary: GET requests with Basic Auth has side effects
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Candlepin
Classification: Community
Component: candlepin
Version: 0.5
Hardware: Unspecified
OS: Solaris
unspecified
high
Target Milestone: ---
: ---
Assignee: Devan Goodwin
QA Contact: John Sefler
URL:
Whiteboard:
Depends On:
Blocks: 568421
TreeView+ depends on / blocked
 
Reported: 2011-03-11 21:34 UTC by Brenton Leanhardt
Modified: 2015-05-14 15:23 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-15 13:10:58 UTC


Attachments (Terms of Use)

Description Brenton Leanhardt 2011-03-11 21:34:16 UTC
Description of problem:
Previously we had assumed that the only way for owners to be created by end users was the following:

Registration: POST to /consumers
Refresh Pools: PUT to /owners/[org id]/subscriptions

When we discovered two owners had been corrupted in QA we learned that the BasicAuth interceptor creates an owner any time it can't find one.  That means GET requests have side effects and it makes the Candlepin API a lot harder to shard than we expected.

Version-Release number of selected component (if applicable):
0.2.11

How reproducible:

In QA:

Steps to Reproduce:
1. Register a consumer
2. Force register a consumer using the same consumerid you just received
  * This results in an unregister which deletes the consumer
  * The client tool then does a GET /consumers/[consumerid from #1]
  * The routing app correctly returns a 404 since it was deleted, but at this point a duplicate owner has been created on another shard
3. Register a new consumer
4. Go to RHSM-WEB.  You will not see any consumer data from your original shard.
  
Expected results:
IMO, Owners should only be auto created on POSTs.  Even the PUT in refresh pools seems odd.

Additional info:
We believe we can work around this though it could make the routing application even more complex.

Comment 1 Devan Goodwin 2011-04-08 11:45:52 UTC
Removed the assumed creation of an owner during basic auth, but kept it during consumer registration.

Applied in candlepin.git:

master: 79cb96f8ccef041c78661ffb92315b867dcd680c
0.2: f5161b2e7ee085aaa10130f524d05d0cd461e310

Should appear in 0.2.16 build.

Comment 2 John Sefler 2011-04-09 13:05:45 UTC
Although not a conclusive verification for Devan's fix in comment 1 especially since I am running my tests against a singly shared onpremises candepin server, I did run our automated bucket of tests as a "no-break" level of confidence run.  The results are consistent with the same test suite run prior to Devan's code change.  This is good.

Here is a link to the test report summary:
http://hudson.rhq.lab.eng.bos.redhat.com:8080/hudson/view/Entitlement/job/subscription-manager%20%28OnPremises%29%20RHEL6/100/TestNG_Report/

Moreover, the log shows that that the test suite did indeed pull in Devan's commit for the candlepin 0.2 branch:
201104080926:45.967 - FINE: ssh root.redhat.com cd /root/candlepin; git checkout 0.2; git pull origin 0.2 (com.redhat.qe.tools.SSHCommandRunner.run)
201104080926:47.268 - FINE: Stdout: 
Your branch is ahead of 'origin/0.2' by 87 commits.
Updating 9063f74..f5161b2
Fast-forward
 .../fedoraproject/candlepin/auth/Principal.java    |    4 ++
 .../candlepin/resource/ConsumerResource.java       |   42 ++++++++++++++++----
 .../candlepin/resteasy/interceptor/BasicAuth.java  |    9 ++--
 3 files changed, 42 insertions(+), 13 deletions(-)
 (com.redhat.qe.tools.SSHCommandRunner.runCommandAndWait)
201104080926:47.269 - FINE: Stderr: 
Switched to branch '0.2'
From git://git.fedorahosted.org/candlepin
 * branch            0.2        -> FETCH_HEAD

Comment 3 Amanda Carter 2011-09-14 21:22:45 UTC
Brenton, can you confirm that this BZ is resolved?

Comment 4 Brenton Leanhardt 2011-09-15 12:18:27 UTC
Yes, I just tested again against 0.4.14 and this bug is resolved.

Here's how I tested:

1) I found an owner on 1 shard and fetched his org_id.
2) I looked up the username and password for that user in the dev environment
3) I issued a /owners/[org_id]/info request to another shard (in the same environment) using basic auth with the users credentials and made sure I received a 404
4) I reissued the command to make sure I still received a 404


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