Simo, need some input on you on how you think the REST pages should be registered.
I've tried a few methods and haven't been really happy with any of them. Here is what I've tried.
1. Make the REST pages a subclass of AdminPage. It really is in a way because they are for administration. The problem I had was with the template and Page abstraction. It doesn't really fit and setting lots of stuff to None just seems wrong.
2. Make a whole new set of classes similar to AdminPage but using different subclassing so it doesn't originate at Page. This adds a whole ton of new code for a fairly small feature (at least right now we're just talking a small part of saml2).
3. Make REST pages a hybrid, subclassing from AdminPage but doing all the plugin loading manually, so self.rest = blahblahblah(). Pretty muich same issues as #2.
4. I considered abstracting AdminPage further to make it support both Page and REST but never started coding that one.
I keep going back and forth on things. These are administrative mount points, so AdminPage seems natural, but they aren't pages, so not so much. They require admin access, so AdmiNPage seems natural, but bleh on the other parts.
I think that pretty much any option is going to require a fair bit of grunt coding of classes to make it work (lots of code, probably not a ton of effort).
Rather than choosing one and getting picked apart at review, lets come up with some plan in advance :-)
rob
On 02/10/2015 04:46 PM, Rob Crittenden wrote:
Simo, need some input on you on how you think the REST pages should be registered.
I've tried a few methods and haven't been really happy with any of them. Here is what I've tried.
- Make the REST pages a subclass of AdminPage. It really is in a way
because they are for administration. The problem I had was with the template and Page abstraction. It doesn't really fit and setting lots of stuff to None just seems wrong.
- Make a whole new set of classes similar to AdminPage but using
different subclassing so it doesn't originate at Page. This adds a whole ton of new code for a fairly small feature (at least right now we're just talking a small part of saml2).
- Make REST pages a hybrid, subclassing from AdminPage but doing all
the plugin loading manually, so self.rest = blahblahblah(). Pretty muich same issues as #2.
- I considered abstracting AdminPage further to make it support both
Page and REST but never started coding that one.
I keep going back and forth on things. These are administrative mount points, so AdminPage seems natural, but they aren't pages, so not so much. They require admin access, so AdmiNPage seems natural, but bleh on the other parts.
I think that pretty much any option is going to require a fair bit of grunt coding of classes to make it work (lots of code, probably not a ton of effort).
Rather than choosing one and getting picked apart at review, lets come up with some plan in advance :-)
Wise!
rob _______________________________________________ ipsilon mailing list ipsilon@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/ipsilon
On Tue, 2015-02-10 at 16:46 -0500, Rob Crittenden wrote:
Simo, need some input on you on how you think the REST pages should be registered.
I've tried a few methods and haven't been really happy with any of them. Here is what I've tried.
- Make the REST pages a subclass of AdminPage. It really is in a way
because they are for administration. The problem I had was with the template and Page abstraction. It doesn't really fit and setting lots of stuff to None just seems wrong.
- Make a whole new set of classes similar to AdminPage but using
different subclassing so it doesn't originate at Page. This adds a whole ton of new code for a fairly small feature (at least right now we're just talking a small part of saml2).
- Make REST pages a hybrid, subclassing from AdminPage but doing all
the plugin loading manually, so self.rest = blahblahblah(). Pretty muich same issues as #2.
- I considered abstracting AdminPage further to make it support both
Page and REST but never started coding that one.
I keep going back and forth on things. These are administrative mount points, so AdminPage seems natural, but they aren't pages, so not so much. They require admin access, so AdmiNPage seems natural, but bleh on the other parts.
I think that pretty much any option is going to require a fair bit of grunt coding of classes to make it work (lots of code, probably not a ton of effort).
Rather than choosing one and getting picked apart at review, lets come up with some plan in advance :-)
Makes sense, some random thoughts about the whole problem:
1. REST API is not exclusively for admin features, for example we want to allow automatic SP registration for SAML SPs, and I see that as non-admin, although it is currently implemented via an admin page.
2. We may want a different auth entry point on REST (to allow unattended operations), for example enabling BASIC AUTH there instead of using Forms.
3. We probably want to expose REST as a separate subtree, I was thinking something like: /idp/rest/auth/<plugin>/... /idp/rest/providers/<provider>/...
Yet there are quite a number of things we certainly do not want to replicate, so we want to make sure both entry-points hit the same logic. Also I think in the long term we'll probably develop an ajax application that just uses the REST endpoints and remove most of the admin pages as they are now.
So perhaps you get close with 4 in the sense that we should split AdminPage into AdminPage + ActionPage and put the logic into ActionPage, then build RestPage that also calls the logic in the corresponding ActionPage.
AdminPage would derive from Page, but RestPage perhaps shouldn't, I guess we need slightly different behaviors between a browser oriented page and an automation oriented one after all.
I haven't thought well yet how to register the outward facing pages automatically, that should probably be done within the providers anyway, just like we do now for the Admin Pages.
Simo.
Simo Sorce wrote:
On Tue, 2015-02-10 at 16:46 -0500, Rob Crittenden wrote:
Simo, need some input on you on how you think the REST pages should be registered.
I've tried a few methods and haven't been really happy with any of them. Here is what I've tried.
- Make the REST pages a subclass of AdminPage. It really is in a way
because they are for administration. The problem I had was with the template and Page abstraction. It doesn't really fit and setting lots of stuff to None just seems wrong.
- Make a whole new set of classes similar to AdminPage but using
different subclassing so it doesn't originate at Page. This adds a whole ton of new code for a fairly small feature (at least right now we're just talking a small part of saml2).
- Make REST pages a hybrid, subclassing from AdminPage but doing all
the plugin loading manually, so self.rest = blahblahblah(). Pretty muich same issues as #2.
- I considered abstracting AdminPage further to make it support both
Page and REST but never started coding that one.
I keep going back and forth on things. These are administrative mount points, so AdminPage seems natural, but they aren't pages, so not so much. They require admin access, so AdmiNPage seems natural, but bleh on the other parts.
I think that pretty much any option is going to require a fair bit of grunt coding of classes to make it work (lots of code, probably not a ton of effort).
Rather than choosing one and getting picked apart at review, lets come up with some plan in advance :-)
Makes sense, some random thoughts about the whole problem:
- REST API is not exclusively for admin features, for example we want
to allow automatic SP registration for SAML SPs, and I see that as non-admin, although it is currently implemented via an admin page.
Oh, I was considering that an administrative feature, I guess it's perspective. Ok, I won't be so concerned about this living in side admin then.
- We may want a different auth entry point on REST (to allow unattended
operations), for example enabling BASIC AUTH there instead of using Forms.
Yes, I was going to tackle that once I got the basic API working. Doing a request to get a cookie first, then the REST API is a pain.
- We probably want to expose REST as a separate subtree, I was thinking
something like: /idp/rest/auth/<plugin>/... /idp/rest/providers/<provider>/...
My thoughts as well. I outlined my ideas on that here: https://fedorahosted.org/ipsilon/wiki/v1/REST
I'm leaning towards having a major version baked into the URI as well ala OpenStack, so /idp/rest/v1/auth/<plugin>
Yet there are quite a number of things we certainly do not want to replicate, so we want to make sure both entry-points hit the same logic. Also I think in the long term we'll probably develop an ajax application that just uses the REST endpoints and remove most of the admin pages as they are now.
So perhaps you get close with 4 in the sense that we should split AdminPage into AdminPage + ActionPage and put the logic into ActionPage, then build RestPage that also calls the logic in the corresponding ActionPage.
AdminPage would derive from Page, but RestPage perhaps shouldn't, I guess we need slightly different behaviors between a browser oriented page and an automation oriented one after all.
I haven't thought well yet how to register the outward facing pages automatically, that should probably be done within the providers anyway, just like we do now for the Admin Pages.
Ok. Gives me quite a lot to chew on. Thanks for the feedback.
rob
On Wed, 2015-02-11 at 10:54 -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Tue, 2015-02-10 at 16:46 -0500, Rob Crittenden wrote:
Simo, need some input on you on how you think the REST pages should be registered.
I've tried a few methods and haven't been really happy with any of them. Here is what I've tried.
- Make the REST pages a subclass of AdminPage. It really is in a way
because they are for administration. The problem I had was with the template and Page abstraction. It doesn't really fit and setting lots of stuff to None just seems wrong.
- Make a whole new set of classes similar to AdminPage but using
different subclassing so it doesn't originate at Page. This adds a whole ton of new code for a fairly small feature (at least right now we're just talking a small part of saml2).
- Make REST pages a hybrid, subclassing from AdminPage but doing all
the plugin loading manually, so self.rest = blahblahblah(). Pretty muich same issues as #2.
- I considered abstracting AdminPage further to make it support both
Page and REST but never started coding that one.
I keep going back and forth on things. These are administrative mount points, so AdminPage seems natural, but they aren't pages, so not so much. They require admin access, so AdmiNPage seems natural, but bleh on the other parts.
I think that pretty much any option is going to require a fair bit of grunt coding of classes to make it work (lots of code, probably not a ton of effort).
Rather than choosing one and getting picked apart at review, lets come up with some plan in advance :-)
Makes sense, some random thoughts about the whole problem:
- REST API is not exclusively for admin features, for example we want
to allow automatic SP registration for SAML SPs, and I see that as non-admin, although it is currently implemented via an admin page.
Oh, I was considering that an administrative feature, I guess it's perspective. Ok, I won't be so concerned about this living in side admin then.
- We may want a different auth entry point on REST (to allow unattended
operations), for example enabling BASIC AUTH there instead of using Forms.
Yes, I was going to tackle that once I got the basic API working. Doing a request to get a cookie first, then the REST API is a pain.
- We probably want to expose REST as a separate subtree, I was thinking
something like: /idp/rest/auth/<plugin>/... /idp/rest/providers/<provider>/...
My thoughts as well. I outlined my ideas on that here: https://fedorahosted.org/ipsilon/wiki/v1/REST
I'm leaning towards having a major version baked into the URI as well ala OpenStack, so /idp/rest/v1/auth/<plugin>
I tend to be very against whole API versions.
I really hate the OpenStack way, as they have these cut points where you have to jump over the new API and then they want to deprecate the old one. That is unfriendly to people that want to write a specific connector and then forget about it.
I prefer to add versions only to specific endpoints if backwards compatible verbs cannot be created.
Yet there are quite a number of things we certainly do not want to replicate, so we want to make sure both entry-points hit the same logic. Also I think in the long term we'll probably develop an ajax application that just uses the REST endpoints and remove most of the admin pages as they are now.
So perhaps you get close with 4 in the sense that we should split AdminPage into AdminPage + ActionPage and put the logic into ActionPage, then build RestPage that also calls the logic in the corresponding ActionPage.
AdminPage would derive from Page, but RestPage perhaps shouldn't, I guess we need slightly different behaviors between a browser oriented page and an automation oriented one after all.
I haven't thought well yet how to register the outward facing pages automatically, that should probably be done within the providers anyway, just like we do now for the Admin Pages.
Ok. Gives me quite a lot to chew on. Thanks for the feedback.
YW, Simo.
Simo Sorce wrote:
On Wed, 2015-02-11 at 10:54 -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Tue, 2015-02-10 at 16:46 -0500, Rob Crittenden wrote:
Simo, need some input on you on how you think the REST pages should be registered.
I've tried a few methods and haven't been really happy with any of them. Here is what I've tried.
- Make the REST pages a subclass of AdminPage. It really is in a way
because they are for administration. The problem I had was with the template and Page abstraction. It doesn't really fit and setting lots of stuff to None just seems wrong.
- Make a whole new set of classes similar to AdminPage but using
different subclassing so it doesn't originate at Page. This adds a whole ton of new code for a fairly small feature (at least right now we're just talking a small part of saml2).
- Make REST pages a hybrid, subclassing from AdminPage but doing all
the plugin loading manually, so self.rest = blahblahblah(). Pretty muich same issues as #2.
- I considered abstracting AdminPage further to make it support both
Page and REST but never started coding that one.
I keep going back and forth on things. These are administrative mount points, so AdminPage seems natural, but they aren't pages, so not so much. They require admin access, so AdmiNPage seems natural, but bleh on the other parts.
I think that pretty much any option is going to require a fair bit of grunt coding of classes to make it work (lots of code, probably not a ton of effort).
Rather than choosing one and getting picked apart at review, lets come up with some plan in advance :-)
Makes sense, some random thoughts about the whole problem:
- REST API is not exclusively for admin features, for example we want
to allow automatic SP registration for SAML SPs, and I see that as non-admin, although it is currently implemented via an admin page.
Oh, I was considering that an administrative feature, I guess it's perspective. Ok, I won't be so concerned about this living in side admin then.
- We may want a different auth entry point on REST (to allow unattended
operations), for example enabling BASIC AUTH there instead of using Forms.
Yes, I was going to tackle that once I got the basic API working. Doing a request to get a cookie first, then the REST API is a pain.
- We probably want to expose REST as a separate subtree, I was thinking
something like: /idp/rest/auth/<plugin>/... /idp/rest/providers/<provider>/...
My thoughts as well. I outlined my ideas on that here: https://fedorahosted.org/ipsilon/wiki/v1/REST
I'm leaning towards having a major version baked into the URI as well ala OpenStack, so /idp/rest/v1/auth/<plugin>
I tend to be very against whole API versions.
I really hate the OpenStack way, as they have these cut points where you have to jump over the new API and then they want to deprecate the old one. That is unfriendly to people that want to write a specific connector and then forget about it.
I prefer to add versions only to specific endpoints if backwards compatible verbs cannot be created.
Well, with REST it's more noun's with implied verbs via HTTP method. It is more a matter of what is the expected inputs and outputs.
By having a version in the URI it grants freedom if you want to refactor things and still provide backwards compatibility to existing clients.
Per-endpoint versioning is still possible via either a special X-header or an embedded version in the request but then your either left with a bunch of hoops to jump through internally with endless if/then/else based on version or you simply reject some requests.
And now I'm hung up again on admin vs not admin.
I'm inclined right now to create a new class to be loaded by a PluginLoader, a REST class. I don't think there is any reason the admin code can't call this internally. So if the API isn't truly administrative I think it would be easier (and cleaner) to separate the two.
rob
On Wed, 2015-02-11 at 15:25 -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Wed, 2015-02-11 at 10:54 -0500, Rob Crittenden wrote:
Simo Sorce wrote:
On Tue, 2015-02-10 at 16:46 -0500, Rob Crittenden wrote:
Simo, need some input on you on how you think the REST pages should be registered.
I've tried a few methods and haven't been really happy with any of them. Here is what I've tried.
- Make the REST pages a subclass of AdminPage. It really is in a way
because they are for administration. The problem I had was with the template and Page abstraction. It doesn't really fit and setting lots of stuff to None just seems wrong.
- Make a whole new set of classes similar to AdminPage but using
different subclassing so it doesn't originate at Page. This adds a whole ton of new code for a fairly small feature (at least right now we're just talking a small part of saml2).
- Make REST pages a hybrid, subclassing from AdminPage but doing all
the plugin loading manually, so self.rest = blahblahblah(). Pretty muich same issues as #2.
- I considered abstracting AdminPage further to make it support both
Page and REST but never started coding that one.
I keep going back and forth on things. These are administrative mount points, so AdminPage seems natural, but they aren't pages, so not so much. They require admin access, so AdmiNPage seems natural, but bleh on the other parts.
I think that pretty much any option is going to require a fair bit of grunt coding of classes to make it work (lots of code, probably not a ton of effort).
Rather than choosing one and getting picked apart at review, lets come up with some plan in advance :-)
Makes sense, some random thoughts about the whole problem:
- REST API is not exclusively for admin features, for example we want
to allow automatic SP registration for SAML SPs, and I see that as non-admin, although it is currently implemented via an admin page.
Oh, I was considering that an administrative feature, I guess it's perspective. Ok, I won't be so concerned about this living in side admin then.
- We may want a different auth entry point on REST (to allow unattended
operations), for example enabling BASIC AUTH there instead of using Forms.
Yes, I was going to tackle that once I got the basic API working. Doing a request to get a cookie first, then the REST API is a pain.
- We probably want to expose REST as a separate subtree, I was thinking
something like: /idp/rest/auth/<plugin>/... /idp/rest/providers/<provider>/...
My thoughts as well. I outlined my ideas on that here: https://fedorahosted.org/ipsilon/wiki/v1/REST
I'm leaning towards having a major version baked into the URI as well ala OpenStack, so /idp/rest/v1/auth/<plugin>
I tend to be very against whole API versions.
I really hate the OpenStack way, as they have these cut points where you have to jump over the new API and then they want to deprecate the old one. That is unfriendly to people that want to write a specific connector and then forget about it.
I prefer to add versions only to specific endpoints if backwards compatible verbs cannot be created.
Well, with REST it's more noun's with implied verbs via HTTP method. It is more a matter of what is the expected inputs and outputs.
By having a version in the URI it grants freedom if you want to refactor things and still provide backwards compatibility to existing clients.
Per-endpoint versioning is still possible via either a special X-header or an embedded version in the request but then your either left with a bunch of hoops to jump through internally with endless if/then/else based on version or you simply reject some requests.
you can still do it with nouns if you want, just not at the whole api level: /idp/rest/sps/sp1/v2 for example If you have to support 2 apis you still need to have if/else stuff in your code, and I prefer to keep it in the function implementation rather than artificially in 2 very separate objects like: /v1/sps/sp1 and /v2/sps/sp1 which in our current implementation would end up as separate python objects.
And now I'm hung up again on admin vs not admin.
I'm inclined right now to create a new class to be loaded by a PluginLoader, a REST class. I don't think there is any reason the admin code can't call this internally. So if the API isn't truly administrative I think it would be easier (and cleaner) to separate the two.
Yes, this is what I was leaning for too, but you do not need to wire it up to the pluginLoader, it could be something returned by the initialization. Currently we check if the provider main object has a self.admin entry, and if so, we wire it up and expose it. We can do a similar thing for rest (have a self.rest) and then set up the REST endpoint in Root() like we do for Admin()
Simo.
On 02/11/2015 07:09 AM, Simo Sorce wrote:
On Tue, 2015-02-10 at 16:46 -0500, Rob Crittenden wrote:
Simo, need some input on you on how you think the REST pages should be registered.
I've tried a few methods and haven't been really happy with any of them. Here is what I've tried.
- Make the REST pages a subclass of AdminPage. It really is in a way
because they are for administration. The problem I had was with the template and Page abstraction. It doesn't really fit and setting lots of stuff to None just seems wrong.
- Make a whole new set of classes similar to AdminPage but using
different subclassing so it doesn't originate at Page. This adds a whole ton of new code for a fairly small feature (at least right now we're just talking a small part of saml2).
- Make REST pages a hybrid, subclassing from AdminPage but doing all
the plugin loading manually, so self.rest = blahblahblah(). Pretty muich same issues as #2.
- I considered abstracting AdminPage further to make it support both
Page and REST but never started coding that one.
I keep going back and forth on things. These are administrative mount points, so AdminPage seems natural, but they aren't pages, so not so much. They require admin access, so AdmiNPage seems natural, but bleh on the other parts.
I think that pretty much any option is going to require a fair bit of grunt coding of classes to make it work (lots of code, probably not a ton of effort).
Rather than choosing one and getting picked apart at review, lets come up with some plan in advance :-)
Makes sense, some random thoughts about the whole problem:
- REST API is not exclusively for admin features, for example we want
to allow automatic SP registration for SAML SPs, and I see that as non-admin, although it is currently implemented via an admin page.
- We may want a different auth entry point on REST (to allow unattended
operations), for example enabling BASIC AUTH there instead of using Forms.
- We probably want to expose REST as a separate subtree, I was thinking
something like: /idp/rest/auth/<plugin>/... /idp/rest/providers/<provider>/...
Yet there are quite a number of things we certainly do not want to replicate, so we want to make sure both entry-points hit the same logic. Also I think in the long term we'll probably develop an ajax application that just uses the REST endpoints and remove most of the admin pages as they are now.
So perhaps you get close with 4 in the sense that we should split AdminPage into AdminPage + ActionPage and put the logic into ActionPage, then build RestPage that also calls the logic in the corresponding ActionPage.
AdminPage would derive from Page, but RestPage perhaps shouldn't, I guess we need slightly different behaviors between a browser oriented page and an automation oriented one after all.
I haven't thought well yet how to register the outward facing pages automatically, that should probably be done within the providers anyway, just like we do now for the Admin Pages.
Just a heads up, like Rob I'm also contemplating the page dispatch logic and how it's wired up to specific classes in order to support ECP.
I know that some page handlers will need to be authenticated by either cherrypy (basic or digest) and/or by Apache (via REMOTE_USER).
Some of the logic which is now in the SSO and Login is going to need to be moved to so it can be shared, this could be done via a super class, a mixin class, or by calling utility functions. I'm still figuring out the best way to do this (it's what I was looking at just prior to my PTO and now that I'm back it's what I've resumed working on). I don't have specific recommendations yet, I expect I will in a day or so. Some of this probably impacts the organization changes Rob is contemplating.
On Wed, 2015-02-11 at 18:18 -0500, John Dennis wrote:
On 02/11/2015 07:09 AM, Simo Sorce wrote:
On Tue, 2015-02-10 at 16:46 -0500, Rob Crittenden wrote:
Simo, need some input on you on how you think the REST pages should be registered.
I've tried a few methods and haven't been really happy with any of them. Here is what I've tried.
- Make the REST pages a subclass of AdminPage. It really is in a way
because they are for administration. The problem I had was with the template and Page abstraction. It doesn't really fit and setting lots of stuff to None just seems wrong.
- Make a whole new set of classes similar to AdminPage but using
different subclassing so it doesn't originate at Page. This adds a whole ton of new code for a fairly small feature (at least right now we're just talking a small part of saml2).
- Make REST pages a hybrid, subclassing from AdminPage but doing all
the plugin loading manually, so self.rest = blahblahblah(). Pretty muich same issues as #2.
- I considered abstracting AdminPage further to make it support both
Page and REST but never started coding that one.
I keep going back and forth on things. These are administrative mount points, so AdminPage seems natural, but they aren't pages, so not so much. They require admin access, so AdmiNPage seems natural, but bleh on the other parts.
I think that pretty much any option is going to require a fair bit of grunt coding of classes to make it work (lots of code, probably not a ton of effort).
Rather than choosing one and getting picked apart at review, lets come up with some plan in advance :-)
Makes sense, some random thoughts about the whole problem:
- REST API is not exclusively for admin features, for example we want
to allow automatic SP registration for SAML SPs, and I see that as non-admin, although it is currently implemented via an admin page.
- We may want a different auth entry point on REST (to allow unattended
operations), for example enabling BASIC AUTH there instead of using Forms.
- We probably want to expose REST as a separate subtree, I was thinking
something like: /idp/rest/auth/<plugin>/... /idp/rest/providers/<provider>/...
Yet there are quite a number of things we certainly do not want to replicate, so we want to make sure both entry-points hit the same logic. Also I think in the long term we'll probably develop an ajax application that just uses the REST endpoints and remove most of the admin pages as they are now.
So perhaps you get close with 4 in the sense that we should split AdminPage into AdminPage + ActionPage and put the logic into ActionPage, then build RestPage that also calls the logic in the corresponding ActionPage.
AdminPage would derive from Page, but RestPage perhaps shouldn't, I guess we need slightly different behaviors between a browser oriented page and an automation oriented one after all.
I haven't thought well yet how to register the outward facing pages automatically, that should probably be done within the providers anyway, just like we do now for the Admin Pages.
Just a heads up, like Rob I'm also contemplating the page dispatch logic and how it's wired up to specific classes in order to support ECP.
I know that some page handlers will need to be authenticated by either cherrypy (basic or digest) and/or by Apache (via REMOTE_USER).
Some of the logic which is now in the SSO and Login is going to need to be moved to so it can be shared, this could be done via a super class, a mixin class, or by calling utility functions. I'm still figuring out the best way to do this (it's what I was looking at just prior to my PTO and now that I'm back it's what I've resumed working on). I don't have specific recommendations yet, I expect I will in a day or so. Some of this probably impacts the organization changes Rob is contemplating.
Ok, once you and Rob have better ideas perhaps we should call an online meeting and hash out various possibilities, then settles on a design that handles all uses cases so we do not have to diverge within the code base and re-implement different strategies in different parts of the code.
Simo.
ipsilon@lists.fedorahosted.org
-
Dmitri Pal -
John Dennis -
Rob Crittenden -
Simo Sorce