By default we should be using the fallback implementation of the
requests Python module: http://docs.python-requests.org/en/master/user/
authentication/#netrc-authentication
So just adding ~/.netrc file should therefore be sufficient to pass
credentials via basic auth.
On So, 2016-10-16 at 10:07 -0700, David McLaughlin wrote:
> 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,
> > >
> >
>
