[Patch] 0002-List-paging-on-CA-and-DRM
by Andrew Wnuk
List paging on CA and DRM
This patch resolves multiple issues related to paging on request,
certificate, and key lists.
It also provides consistent behavior across all lists.
Bug: 768138.
This patch has been reviewed and tested for RHCS8 branches.
13 years, 2 months
[Patch] 0002-Big-numbers-fix-for-CA-and-DRM
by Andrew Wnuk
This patch resolves multiple issues related to use of big numbers on CA
and DRM
It also provides a fix for incomplete recovery requests causing null
pointer exception.
Bugs: 756133, 758505.
This patch has been reviewed and tested for RHCS8 branches.
13 years, 2 months
[PATCH] pki-vakwetu-0010-Changes-to-pkicreate-to-create-resteasy-links.patch
by Ade Lee
This patch will allow pkicreate to create the resteasy links needed in
the java subsystems automatically.
The resteasy-jettison-provider patch (which is not delivered with
candlepin-deps) will be delivered (for now) with pki-setup until the
relevant packages can be delivered in Fedora.
Please review.
Thanks,
Ade
13 years, 2 months
[Patch] 0008-Enhanced-new-REST-search-interface-for-keys-and-key-.patch
by Ade Lee
Hi all,
Enhanced new REST search interface for keys and key requests
Defined parameters that can be searched for in key and keyrequest searches.
Searches for KeyRequests and Keys will perform VLV searches if those searches are defined.
The results will include links to next and previous pages in the results.
Also added maxTime and maxResults parameters for regular searches. These will be operational
unless they exceed server defined limits - which are enforced at the repo level.
This requires my previous framework patch to be applied first.
Please review.
Thanks,
Ade
13 years, 2 months
skeleton code for drm restful interface
by Ade Lee
Attached is some skeleton code for the new DRM interface. To build, you
will need to download and install the candlepin-deps rpm.
(http://repos.fedorapeople.org/repos/candlepin/candlepin/)
We will use these rpms to build/run until we get the resteasy packages
into Fedora.
The new classes provide the following:
1. interface to list/get/submit key requests (for archival and
recovery).
2. interface to recover keys
3. interface to approve/reject key recovery requests.
4. input/output via XML/JSON/browser.
This is pretty much just a skeleton as not all the functionality is
currently in the DRM. There is also no authentication/authz as Jack has
yet to work that part out. But it does look pretty much like what the
restful interface will probably look like - and the comments point out
the parts that are missing.
Jack - please look to see how your new code would interact with this -
and also in terms of the input/output parameters/structures.
Endi, Adam: please look to see if the structure/ coding makes sense - or
if it can be improved. Its not at all final - but all feedback will
help.
To test, you can do the following:
1. Build the code. You will need to replace pki-common and pki-kra.
2. pkicreate and configure a DRM. The needed changes to web.xml should
be in the new instance.
3. Add links to the following jars in webapps/lib/. They should all be
in /usr/share/candlepin/lib
--> javassist, jaxrs-api, jettison, resteasy-jaxb-provider,
resteasy-jaxrs, resteasy-jettison-provider, scannotation
4. Archive some keys by doing enrollments with your CA or TPS.
You could also set up the DRM instance to be controlled by eclipse in
the same way that we do for the CA instance. If you do this, you will
be able to step through the code with the debugger.
You should be able to see archived enrollments/ recoveries by going to :
https://hostname:port/kra/pki/keyrequests
https://hostname:port/kra/pki/keyrequest/1
using a browser, or using curl to get xml or json.
Ade
13 years, 2 months
[PATCH] 0025-Simple-Name
by Adam Young
This is not ready for commit, but I want people to start getting eyes
on it. I know it builds but have not checked beyond that part. I am
reworking a large number of changes into a set of manageble sized
patches and I think I have all of the dependencies for these changes in
this patch, but I have not yet confirmed that.
13 years, 2 months
thinking about the proposed RESTful interface
by Ade Lee
Endi recently brought up the question as to whether we should change the
conventions we have proposed for the REST interface URI mapping for
resources.
Proposal A:
The current proposed convention is to use plural for collections, and
singular for individual resources, as follows:
GET /pki/keyrequests -- get collection (list) of key requests
GET /pki/keyrequest/X -- get key request for id X
Proposal B:
Endi proposes to simply put everything under the plural, as follows:
GET /pki/keyrequests -- get collection (list) of key requests
GET /pki/keyrequests/X -- get key request for id X
A good place to see even more suggested alternatives is here:
http://redrata.com/restful-uri-design/
************************
Proposal A
Pros:
1. There is no convention in general on how these things should be
named. Proposal A was selected because it is the convention employed by
a default configuration in Rails.
2. What we expect to return -- a collection of key requests (which is
just a list of urls with some abbreviated data about the requests), and
the request data itself -- are two different entities.
Using /keyrequests and /keyrequest makes that explicit.
3. To me, this just seems more intuitive. More on that can be seen
here:
http://blog.roberthahn.ca/articles/2007/04/06/url-design/
Cons:
1. The URL is not hackable -- ie. you need to handle
GET /pki/keyrequest where no $id is provided. You could return an
error - or you could redirect to /pki/keyrequests. We should decide
which is most appropriate.
*************************
Proposal B:
Pros:
1. The URL is hackable. That is - if I take /pki/keyrequests/id and
hack off id, then I still get a valid URL.
Cons:
1. You may want to have queries that look like the following:
GET /pki/keyrequests/recent
GET /pki/users/admins
In these cases, I am looking for collections of users matching a
particular characteristic. For example, I am looking for the collection
of users that are admins, rather than the user named "admins". Proposal
B has the possibility of name conflict , whereas proposal A does not.
In proposal A, it is immediately clear whether I want a collection
(named or otherwise) or an individual resource - and I can be free to
qualify my collections as I see fit.
********************
Based on the above, I'm inclined to stick with Proposal A. In the link
above, they mentioned some other alternatives - which IMHO - are overly
complicated.
But I'm opening this for debate. Let the sparring begin!
Ade
13 years, 2 months
