Bug 684350

Summary:	GET requests with Basic Auth has side effects
Product:	[Community] Candlepin	Reporter:	Brenton Leanhardt <bleanhar>
Component:	candlepin	Assignee:	Devan Goodwin <dgoodwin>
Status:	CLOSED CURRENTRELEASE	QA Contact:	John Sefler <jsefler>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	0.5	CC:	acarter, dgoodwin
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Solaris
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-09-15 13:10:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	568421

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