Implement license checking

[Former user]

It would be great if this framework can do the licence checking by providing a request validator which checks the lic=active request param sent by Atlassian products and provide a simple error page if validation fails.

[Alex Wei]

Would you provide more details on this? Is there a documentation on the lic=active request param? Is it a request param specific to a particular product like JIRA or Confluence?

[Nader Hadji Ghanbari]

Yes. It is supported for all platform with Atlassian Connect support (with some caveats).

We implemented this on our framework (which is dependent on ac-play-scala). If you guys are ok with this we can make a pull request from it.

It seems also necessary to do the license checking by using the REST API sometimes (for instance JIRA webhooks does not carry the lic parameter for some reason, I guess there should be a technical challenge for Atlassian guys to deliver this as there is a feature request in Atlassian ecosystem about this for quite some time). Anyway we do this for webhooks by calling the REST API, if this is of any added value we can make a pull request from it as well.

[Alex Wei]

Hi Nader, it'll be really appreciated if you can make a PR on this. And would you please post a link to the related documentation here for us who are not familiar with this to understand it better?

[Nader Hadji Ghanbari]

Sure Alex.

Here is a link to the Licensing section in Atlassian Connect docs:

License Status

Basically Atlassian Host verifies everything (if add-on asks for it by providing "enableLicensing": true in the atlassian-connect.json descriptor) then it sends a request query param, namely lic to the add-on (for instance when rendering a web panel or page). As the add-on you only need to check that the value of this parameter is active.

Unfortunately this does not work for WebHooks so far, so for them you have to check the license manually by sending a RESt request to s"/rest/atlassian-connect/1/addons/$addonKey" (using Scala interpolated strings :D) and then check the contents of the response. Details on this way here: https://developer.atlassian.com/static/connect/docs/latest/rest-apis/#get-addons-addonkey

[Nader Hadji Ghanbari]

I think it might be simpler to start with just the simple checker and add the rest checker later, what do you think?

[Alex Wei]

Nader, sounds good to me. And thanks for the link, it all makes sense to me now...

[Nader Hadji Ghanbari]

By the way there is no way to test the licensing in a local machine (dev mode) as it's mentioned in docs.

So what we did is to add a config (ac.check.license) to Play configurations to disable the license checking. There are multiple options here which needs a detailed discussion but please share your thoughts.

Some of the options:

1. Just write a simple LicenseChecker which returns true or false (or throws exception) and let add-ons use it if they want
2. Write a license checker which is aware of a Play configuration (enable or disable license checking)
3. Add the logic to JWTAction validators so that by using them license checking is done automatically (needs the configuration for sure)
4. Write some new Actions which are able to do the JWT validation and license checking in a general way (probably you need the config here as well, unless you can pass a boolean to them to defer the decision to later)

Having a configuration simplifies things to some extent (at least it did for us), having actions also makes it much easier than composing the action yourself.

[Nader Hadji Ghanbari]

I made a pull request with the first option mentioned above (simple request checker). Didn't document it though, if u guys are ok with this will update the PR by adding some instructions.

BTW we are now in production relying on this project :) It was really a smooth ride, so than you guys.

p.s. I have some concerns regarding easier contribution to this project, do you guys have some time for this discussion?

[Alex Wei]

Thanks for the PR. What are your ideas about easier contribution to this project? If you would like to discuss privately, you can email me at awei at atlassian dot com. Since Play is no longer a preferred choice in Scala framework in Atlassian, this project is not actively worked on. So I would really like to see you guys taking more control over this project.

[Nader Hadji Ghanbari]

Sure, it's nothing private but email is more convenient I guess (more or less about the plan to maintain this project and how to handle huge improvement batches).

Just out of curiosity, is there another Scala framework for Atlassian Connect? :) If yes, may I ask what is being used instead of Play?

[Alex Wei]

No problem. I'll be looking forward to your email then.

As for Scala framework for Atlassian Connect, as far as I know, there was a Spray one done as an innovation week a year ago. There has been no further development since then.

As for other Scala projects, most of the projects that I know of use Finagle, Spray and http4s.