Yes.. basically the objective here is to enable clientAuth for a webapp..
Thanks & regards,
-Prabath
On Wed, Feb 3, 2016 at 9:52 AM, Rajjaz Mohammed wrote:
> Hi Dimuthu,
>
> @prabath/johan/malaka please correct me if I’m wrong.
> in the last meeting with prabath, johan and
This doc has to go to the README.md file in the archetype dir
On Thu, Feb 4, 2016 at 9:13 PM, Manuri Amaya Perera
wrote:
> Hi Azeez,
>
> I have sent the PR[1]. And please find the documentation here[2].
>
> [1] https://github.com/wso2/msf4j/pull/124
> [2]
>
Hi All,
Currently, we are displaying all the asset level fields (attributes) on the
publisher side, and version and name attribute only in the Store. The
decision to display all the of the available fields in the Store asset
details page depends on the end user business requirements. In most of
Thanks Aruna for the answers!
On Thu, Feb 4, 2016 at 10:10 AM, Manuri Amaya Perera
wrote:
> Hi Imesh,
>
> Aruna has explained the answers to your questions.
> Also you can find the previous discussion on creating maven archetypes for
> a generic osgi bundle and a carbon
Hi Azeez,
I have sent the PR[1]. And please find the documentation here[2].
[1] https://github.com/wso2/msf4j/pull/124
[2]
https://docs.google.com/a/wso2.com/document/d/1A5iS6JxbqVuazFwe_EVKeuaXiwCVzOoYOUlA7LSPTPY/edit?usp=sharing
Thank you.
On Thu, Feb 4, 2016 at 8:40 AM, Manuri Amaya Perera
Need some improvements to this PR. Let's add "//TODO" to all four methods
along with "Implementation for HTTP <> request" as the comment. And as the
class level comment for "Microservice" class, let's point to the getting
started guide - https://github.com/wso2/msf4j#getting-started, so that the
Hi Tharika,
Have you decided on the security of this endpoint?
Thanks,
NuwanD.
On Thu, Feb 4, 2016 at 9:52 PM, Tharika Madurapperuma
wrote:
> Hi All,
>
> We are planning of $subject.
>
> In some use cases, it is desirable or necessary to allow OAuth clients to
> obtain
Hi Tharika,
+1. Have you thought about a way to fetch/update a DCR application?
There is a way you can achieve this by providing an access_token and
registration URL upon DCR registration. So then users can persist that
access_token and URL and can be used in future in order to edit the DCR
Hi All,
We are planning of $subject.
In some use cases, it is desirable or necessary to allow OAuth clients to
obtain authorization from an authorization server without the two parties
having previously interacted. Therefore in order for the authorization
server to accurately represent to end
Hi Manuri,
I think it is better to separately explain the dynamic parameters user can
change(project group id, version etc), when they build the project from
Archetype. Also, we can mention, for what the example is for? "Building
your own project from the WSO2 MSF4J archetype".
Thanks.
On Thu,
Hi Tharika,
Since *"**saasApp"* is not a common parameter as per the spec, you might
have to emphasise the usage of it.
Just noticed that in the excerpt you've provided request is sent to a
resource named oauthdcr. Better if we can name it as /regsiter to show the
conformity with the spec.
On
11 matches
Mail list logo