I noticed this while I was reviewing the patch to add cookies - I couldn't
find any HTTP basic auth support in the client. We'd need a patch to wire
that up (with some method of getting the user credentials).

I think this confirms my concern about adding auth support on only one side
of the CLI/Scheduler :)

On Sun, Oct 16, 2016 at 9:46 AM, Stephan Erb <s...@apache.org> wrote:

> Hi,
>
> would it be possible to show us your relevant scheduler configuration and
> your ini file?  This will make it easier to reproduce the issue.
>
> Thanks,
> Stephan
>
> On Do, 2016-10-13 at 17:58 +0000, Ajmera, Jatan wrote:
>
> Hi,
>
> I was previously communicating about this issue on the slack channel
> sometime back. I am having troubles when i am trying to configure the HTTP
> Basic Auth for my aurora scheduler on my Mesos Cluster. I have configured
> the necessary flags at deploy time along with the other flags and have
> checked the ini file and made sure it had the right permissions as well.
> The logs I see on the master where the scheduler is running are as follows:
>
>
> 80006, negotiated timeout = 4000
> I1013 01:51:09.751 [RedirectMonitor STARTING, 
> ServerSetImpl$ServerSetWatcher:317]
> received initial membership [ServiceInstance(
> serviceEndpoint:Endpoint(host:ec2-54-244-159-201.us-west-2.
> compute.amazonaws.com, port:8081), additionalEndpoints:{http=
> Endpoint(host:ec2-54-244-159-201.us-west-2.compute.amazonaws.com,
> port:8081)}, status:ALIVE)]
> I1013 01:51:09.765 [HttpServerLauncher STARTING, Server:345]
> jetty-9.3.11.v20160721
> W1013 01:51:10.278 [HttpServerLauncher STARTING, Stats:181] Re-using
> already registered variable for key shiro_authorization_failures
> W1013 01:51:10.302 [HttpServerLauncher STARTING, IniRealm:139] Users or
> Roles are already populated.  Configured Ini instance will be ignored.
> W1013 01:51:10.313 [HttpServerLauncher STARTING,
> DefaultWebSecurityManager:173] The 
> org.apache.shiro.web.mgt.DefaultWebSecurityManager
> implementation expects SessionManager instances that implement the
> org.apache.shiro.web.session.mgt.WebSessionManager interface.  The
> configured instance is of type 
> [org.apache.shiro.session.mgt.DefaultSessionManager]
> which does not implement this interface..  This may cause unexpected
> behavior.
> W1013 01:51:10.333 [HttpServerLauncher STARTING, IniRealm:139] Users or
> Roles are already populated.  Configured Ini instance will be ignored.
> W1013 01:51:10.347 [HttpServerLauncher STARTING, IniRealm:139] Users or
> Roles are already populated.  Configured Ini instance will be ignored.
> W1013 01:51:10.351 [HttpServerLauncher STARTING,
> DefaultWebSecurityManager:173] The 
> org.apache.shiro.web.mgt.DefaultWebSecurityManager
> implementation expects SessionManager instances that implement the
> org.apache.shiro.web.session.mgt.WebSessionManager interface.  The
> configured instance is of type 
> [org.apache.shiro.session.mgt.DefaultSessionManager]
> which does not implement this interface..  This may cause unexpected
> behavior.
> W1013 01:51:10.362 [HttpServerLauncher STARTING, IniRealm:139] Users or
> Roles are already populated.  Configured Ini instance will be ignored.
>
>
> And when i try to connect through the client i get a 401 Client
> Error:Unauthorized. It would be really appreciated if you could help me
> figure this out. Also what would be a good approach to secure communication
> from the client to the scheduler.
>
>
> Thanks,
>
>

Reply via email to