On Wed, Oct 15, 2014 at 1:19 PM, Manoj Gunawardena man...@wso2.com wrote:
Hi,
+1 for develop as separate app and more clean and logical way . But I
think user point of view, its more applicable to view and function with in
publisher. Cant we implement as separate Jaggery app and included to
Hi All,
+1 for Johan's opinion. My suggstion is develop as Jaggery web app and
implement as carbon feature. Publisher ship with this feature and admin
pages can navigate through publisher. But this new admin app will be
available to integrate with any other app as feature.
Thanks
On Thu, Oct
Hi all,
As mentioned in a previous mail ( [ES] Workflow extensions support -
Approval task pages or app ? ), we are planning to develop a workflow
extension model for Enterprise strore. Following is the proposed
architecture.
Below diagram explains how the workflow structure fits in to the ES
Thank you all for the suggestions.
On Thu, Oct 16, 2014 at 4:23 PM, Manoj Gunawardena man...@wso2.com wrote:
Hi All,
+1 for Johan's opinion. My suggstion is develop as Jaggery web app and
implement as carbon feature. Publisher ship with this feature and admin
pages can navigate through
Hi,
As we discussed in last time we will let external key manager integrator to
come up with their own application. At the same time we will be maintaining
application object in APIM side to have minimum fields. And other data will
hold as key value pairs. May be we can discuss this further and
Hi,
Cartridge agent is the one what deploy the app when artifact update event
is triggered. I think you can do this by a agent extension. Similar script
as AS can be executed in that extension point.
Touched, not typed. Erroneous words are a feature, not a typo.
Hi,
The API can be secured using either BasicAuth or OAuth. WSO2 IS SCIM
endpoint is one example.
If BasicAuth used, client side might have to store the username/password.
If OAuth used, and the API is accessed via a browser, user can be
redirected to the authorization Server to get
Hi Udara,
As per your suggestion this is the closest point to, artifacts are
deployed in the cartridge. But, this script is executed after syncing the
git repo with cartridge local clone as per the code (correct me if I'm
wrong). In that case we have to assume that updated artifact has been
IMO storing username and password is not the recommended way. So +1 for
oauth security. May be we can have both oauth and basic auth if needed. But
if these endpoints are for third party developers who will write some
client code using it I think oauth is the best way.
Thanks Regards
Danushka
