On Mon, Aug 25, 2014 at 5:03 PM, Vinod Kone wrote:
> See my answers inline.
>
>
>> Based on what you say, looks like there are more HTTP endpoints (rw)
>> exposed to slaves and frameworks, like /shutdown. We don't want to
>> implement auth for these endpoints, atm.
>>
>
> Yes. There are more user
See my answers inline.
> Based on what you say, looks like there are more HTTP endpoints (rw)
> exposed to slaves and frameworks, like /shutdown. We don't want to
> implement auth for these endpoints, atm.
>
Yes. There are more user visible endpoints. See "master:port/help" for the
list of endp
We want t
On Mon, Aug 25, 2014 at 10:40 AM, Vinod Kone wrote:
> Hey Bhuvan,
>
> The "ShutdownFramework" ACL is an example of authN/authZ of HTTP endpoint
> ("/shutdown") from a user perspective. Depending on what HTTP endpoints you
> are planning to auth we could conceivably add more ACLs or add
Hey Bhuvan,
The "ShutdownFramework" ACL is an example of authN/authZ of HTTP endpoint
("/shutdown") from a user perspective. Depending on what HTTP endpoints you
are planning to auth we could conceivably add more ACLs or add a generic
HTTP endpoint ACL. Of course this still doesn't give you sessio
Hello,
We use auth/authz implementation for frameworks and slaves. They are
neat! This thread is about auth for web ui, between master and user.
We are implementing authentication for master web ui (port: 5050). The
master seem to serve both user requests and protobuf messages from
slave & framew
