Dmitri Pal wrote:
On 02/13/2014 06:07 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 01/28/2014 09:35 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 01/23/2014 02:17 PM, Petr Viktorin wrote:
The URL endpoint /ipa/rest suggests that if we implement a complete
API for IPA it would live here. Is the API supposed to be
future-compatible? (The API itself seems to be a good subset of a
complete REST API, but can we easily add an frontend with
authentication, i18n, etc. here later, and keep the limitations for
unauthenticated access?)
Perhaps /ipa/smartproxy would be a better choice?

It was future-proofing. I'm fine with changing the URI, it is
probably a good
thing to save that name.

+1 for moving to /ipa/smartproxy/rest, we will want a complete REST
in ipa/rest/ in the future. I rather opened a ticket to track that:


I think I've addressed most of Petr's suggestions with the exception
of the global ipa handle and I stuck with *args, **options as this is
pretty much standard in IPA calls.

The gssproxy.conf.snippet just makes it easier to copy/paste. I can
drop it if you want, I suppose it is duplication.

Note that I ran this past the Foreman design again and as a result
added another interface, /realm. It was my understanding that this
Foreman design wasn't set into stone but a patch is working its way
through their system that followed the spec so I went ahead and added
it. It isn't a big deal, the Host() class handles it out of the box.

I also updated the design page a bit to reflect some of the changes made.

Right now there are no plans to backport python-kerberos to F20.


Freeipa-devel mailing list

Recently we had a ticket in SSSD
Should we have a similar one for IPA client and especially for the proxy?
Proxy will be a long term running process so dealing with the stale
tickets becomes important for it if replica is re-installed. Is it
something that is solved in API level or on the proxy level?
Should we have a separate ticket for that?

Using gss-proxy so it's not our problem. We never touch tickets.


Freeipa-devel mailing list

Reply via email to