Yeah, see https://github.com/apache/aurora/blob/master/docs/operations/
security.md#http-basic-authentication

On So, 2016-10-16 at 10:26 -0700, David McLaughlin wrote:
> > I *just* seen that in the e2e test. Have we documented that
anywhere? 
> 
> > > On Sun, Oct 16, 2016 at 10:24 AM, Stephan Erb <s...@apache.org>
wrote:
> > By default we should be using the fallback implementation of the
> > > > requests Python module: http://docs.python-requests.org/en/master/u
ser/
> > 
> > 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,
> > 
> > > > >
> > 
> > > >
> > 
> > >
> > 
> > 
> > 
> > 
> 
> 

Reply via email to