copr / copr

Clone

#2122 GSSAPI follow-up for #1820
Closed: Fixed 2 years ago by praiskup. Opened 2 years ago by praiskup.

Closed: Fixed
Reopen Issue
  1. /api_v3/gssapi_login/ should be a real API call -- should return some useful info like username at least
  2. /api_v3/gssapi_login/ should be properly documented
  3. we need to have read-write lock for the coookie file
  4. don't do multiple API calls when not necessary
    - auth_check() should contact frontend only once even if called multiple times
    - no need to call auth_check() api call if /api_v3/gssapi_login/ was called (and 1. is implemented)
  5. After mergin #2102, we should move the session.Session() to one place and instantiate it only once
  6. _get_session_cookie_via_gssapi() should be made API, and properly documented
  7. separate the logic for _get_session_cookie_via_gssapi into two things -- handling the cookie file and getting the sesssion cookie
  8. copr-cli "no config" and "no ticket" raises weird tracebacks
  9. copr-cli "no config" and "no ticket" should write "take a kerberos ticket, or obtain ~/.config/api" -- it should be absolutely obvious one can do just fkinit

Metadata Update from @praiskup:
- Issue tagged with: RFE
2 years ago

Metadata Update from @schlupov:
- Issue assigned to schlupov
2 years ago

Most of the things is done on #2151.

(2) not sure how to document a route?
(5) remains, but something similar is to be done in #2149

Edited 2 years ago by praiskup

(3) is being done in #2150

(10) Also, I asked on infra channel and not every FAS user has the @fedoraproject.org e-mail alias. This pretty much makes our e-mail obtaining method from FAS nicks broken. We'll have to first require the user to log-in via non-GSSAPI method to get the e-mail.
Edited 2 years ago by praiskup

(11) We should handle re-authentication failures. Consider a daemon using our Python API, being logged-in via GSSAPI, and running for a day or two --> session expires, and the API will start failing because of wrong session cookie (we should re-authenticate)

Metadata Update from @praiskup:
- Issue tagged with: release-blocker
2 years ago

Point (10) is a blocker for sure. Going to fix it tomorrow. Then I think we can relax
a bit, do the release and continue post-release.

Metadata Update from @praiskup:
- Issue untagged with: release-blocker
2 years ago

(2) not sure how to document a route?

We don't do that yet for any route, so I would skip the documentation for this route as well. Maybe if you want to dump your brain into text, maybe just use docstring? But I agree that we should prioritize #1865.

(5) After mergin #2102, we should move the session.Session() to one place and instantiate it only once

In PR#2160, I actually dropped the whole requests.Session

(11) We should handle re-authentication failures. Consider a daemon using our Python API, being logged-in via GSSAPI, and running for a day or two --> session expires, and the API will start failing because of wrong session cookie (we should re-authenticate)

This is partially done in PR#2160. I just realized that it doesn't work in all cases, so I will need to do a few adjustments. It will be done within the same PR though ...

This is done in PR#2160
Edited 2 years ago by frostyx

I believe this has been fixed.

Metadata Update from @praiskup:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
2 years ago

Login to comment on this ticket.

Metadata

bug RFE

None
None
High
None
None
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.