auth problems

Asked by Kun Huang

in keystoneauth.py

267 def _authorize_unconfirmed_identity(self, req, obj, referrers, roles):
268 """"
269 Perform authorization for access that does not require a
270 confirmed identity.
271
272 :returns: A boolean if authorization is granted or denied. None if
273 a determination could not be made.
274 """
275 # Allow container sync.
276 if (req.environ.get('swift_sync_key')
277 and (req.environ['swift_sync_key'] ==
278 req.headers.get('x-container-sync-key', None))
279 and 'x-timestamp' in req.headers):
280 log_msg = 'allowing proxy %s for container-sync' % req.remote_addr
281 self.logger.debug(log_msg)
282 return True
283
284 # Check if referrer is allowed.
285 if swift_acl.referrer_allowed(req.referer, referrers):
286 if obj or '.rlistings' in roles:
287 log_msg = 'authorizing %s via referer ACL' % req.referrer
288 self.logger.debug(log_msg)
289 return True
290 return False

My question is in line 290, why return False here but not let this run follow authorizing check? This request may be allowed by other condition.
This is a case here: https://bugs.launchpad.net/swift/+bug/1082973

same codes in tempauth, so what's the design idea here?

Question information

Language:
English Edit question
Status:
Solved
For:
OpenStack Object Storage (swift) Edit question
Assignee:
No assignee Edit question
Solved by:
clayg
Solved:
Last query:
Last reply:
Revision history for this message
Launchpad Janitor (janitor) said :
#1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
Kun Huang (academicgareth) said :
#2

I still need an answer

Revision history for this message
Best clayg (clay-gerrard) said :
#3

That particular snippet looks to just be a two phase check.

I'm reading it as simply asking
 1) is the referrer allowed AND
 2a) it's an object
    OR
 2b) it's a listing enabled container

If you returned True at 290 you'd allows listings of containers that didn't specify .rlisting?

I think the code is valid. I also think bug # 1082973 is valid, but possibly unrelated...

Revision history for this message
Kun Huang (academicgareth) said :
#4

You're right. I checked codes again. That bug is not related about this.

Thanks clayg

Revision history for this message
Kun Huang (academicgareth) said :
#5

Thanks clayg, that solved my question.