I'm confused here.
The example you can use the consumer-key "hardcoded-consumer" along with the provided Public Key/ Shared secret key.
You mention you can instead generate public/private key.
To elaborate:
-The consumer key is made up and the service provider and the consumer both need to know it.
The private key and consumer key is used by the consumer
The public/shared key and the consumer key is used by the service provider
___________________________
So after a day of hacking at the provided java example I worked this out:
To come up with your own Consumer Key as well as using your own generated private and public keys, follow below.
------ Generate Keys ------
-Generate private key
openssl genrsa -out privkey.pem 2048
-Generate public key based off private key
openssl rsa -pubout -in privkey.pem -out pubkey.pem
------ JIRA Admin/UI: ------
-Go to Jira Administration -> Applications -> Application links
(My test, as well as the provided java example is a server-side stand alone client app i.e. doesnt respond to http/negotiate tokens so...)
-Ignore the fact that the thing attempts to connect to the link with which you create the app-link - it can be any url.
-Make up (and remember) any string value for a Consumer Key
-Copy the public key file content excluding the "-----BEGIN PUBLIC KEY-----" and "-----END PUBLIC KEY-----" as well as removing line breaks into the "Shared Secret" field.
(It might work leaving those in but I haven't bothered trying.)
-Set the Request Token URL, Access Token URL, and Authorize URL to the below, respectively, substituting your Atlassian subdomain - provided you're using a hosted instance.
https://<my-hosted-jira>.atlassian.net/plugins/servlet/oauth/request-token
https://<my-hosted-jira>.atlassian.net/plugins/servlet/oauth/access-token
https://<my-hosted-jira>.atlassian.net/plugins/servlet/oauth/authorize
-Check "Create Incoming Link" and hit Continue
-On the next screen add the same Consmer Key you decided on above and copy the content of the public key you generated above as-is.
i.e. INCLUDING the "-----BEGIN PUBLIC KEY-----" , "-----END PUBLIC KEY-----", as well as the line breaks. and hit continue
------ Client Code Changes ------
Update provided example java client found at https://developer.atlassian.com/jiradev/jira-apis/jira-rest-apis/jira-rest-api-tutorials/jira-rest-api-example-oauth-authentication
-Update JIRAOAuthClient class CONSUMER_KEY constant (line 13) to the Consumer Key you decided on above.
-Update JIRAOAuthClient class CONSUMER_PRIVATE_KEY constant (line 14) to the private key. (I kept line breaks and BEGIN and END RSA PRIVATE KEY tags with hyphens etc.)
That code is a pretty good example of the dance.
_______________________________________________________________________
The part that was confusing me was the disconnect between the private and public key.
The client holds on to the private key (generated) and the consumer key (made up).
JIRA requires the consumer key (made up) but also the public key (generated with the private key) and JIRA needs no knowlege of the private key itself, hence it's called private.
Also if I manually go through the dance and hold on to the token and deploy it with my client app, I've read in places that the token lives forever and in others that it lives for a week.
It looks like on my hosted Confluence instance that the token is valid for 5 years.
To do the dance with confluence instead of JIRA, configure the application link in confluence administration, use the same above Request Token URL, Access Token URL, and Authorize URL for the service provider, but all UI admin/config should be done on Confluence and not JIRA. i.e: https://<my-hosted-jira>.atlassian.net/wiki. add the confluence context (in my case 'wiki') when visiting the admin/settings pages.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.