Custom ui resolver callback context element, licensing information

Forge Forge Custom UI and UI kit (beta)
#1

According to https://developer.atlassian.com/platform/forge/runtime-reference/custom-ui-resolver/#arguments we can seem to expect licensing information for production environments in the context element of the callback argument, is that correct?
If so, will the licensing information appear as a property context.license.isActive of type boolean as well?

#2

Hi @UdoHagemannDecadisAG

Thanks for reaching out.

Your assumption is correct, you should be able to write something like the following snippet:

import Resolver from "@forge/resolver";

const resolver = new Resolver();

resolver.define("checkLicense", ({ context }) => {
  return context.license && context.license.isActive;
});

export const handler = resolver.checkLicense();

Hope this helps.

2 Likes
#3

Hi @XavierCaron,

I’m wondering if we can check the license directly from the client-side (Custom UI) instead of invoking a Backend Resolver. As I see in the example, the context variable is sent from the client-side.

It would be nicer if we can directly read it right in the Custom UI component using @forge/bridge.

import { view } from '@forge/bridge';

const context = await view.getContext();
const isLicensed = !!context.license?.isActive
#4

Hi @nhac.tat.nguyen

You are correct, it is a nicer way to get it as it bypasses calling a backend function.

The context returned by the view.getContext() should already provide the license object and therefore, your above snippet should work.

Let me know if you face any issue.

Thanks,
Xavier

#5

Hi @XavierCaron,

does this mean that the constraint imposed by app context security on forge is gone?
We understood that, for security reasons, one should not rely on the results of getContext, since it “is not guaranteed to be secure, unalterable, and valid to be used for authorization”.

Thanks for clarifying!
Cheers, Udo

#6

Hi @UdoHagemannDecadisAG

You are correct, the constraint is still in place and one should not rely on the Custom UI view.getContext content for authorization purposes.

However, one should be able to use those fields for display purposes (ie, show / hide element based on license value).

Hope this clarifies it.

Cheers,
Xavier

1 Like
#7

Thanks for updates on this @XavierCaron. Its a little while since this original thread discussion, I checked using the @forge/resolver approach as that is recommended for enforcement, but at least in my instance req.context does not include a license field (I’m running in development mode). req.context includes at current localId, cloudId, moduleKey, extension, installContext and accountId.

Would be good to get an update if there are any changes to the plan/approach on how to do this, or if there is a specific timeline when it is will be made available. Or will this only be visible in production mode? If so, it would be quite useful for it to be available in development mode so that code can be validated prior to production stage.

Thanks in advance, if anyone has updates on this topic.

Cheers,

Erik

#8

Hello, can I get the license in forge scheduledTrigger? I urgently need to deal with this problem