Yes, Here: https://review.openstack.org/#/c/111756/



From:   Kevin Benton <blak...@gmail.com>
To:     "OpenStack Development Mailing List (not for usage questions)"
            <openstack-dev@lists.openstack.org>
Cc:     isaku.yamah...@gmail.com
Date:   08/04/2014 01:01 PM
Subject:        Re: [openstack-dev] 答???: [Neutron] Auth token in context



That makes sense. Is there a patch up for review to make this available in
the context?


On Mon, Aug 4, 2014 at 8:21 AM, Isaku Yamahata <isaku.yamah...@gmail.com>
wrote:
  ServiceVM wants auth token.
  When creating l3 router which runs inside VM, it launches VM.
  So neutron interacts with other projects like serivcevm server or nova.

  thnaks,


  On Sun, Jul 20, 2014 at 12:14:54AM -0700,
  Kevin Benton <blak...@gmail.com> wrote:

  > That makes sense. Shouldn't we wait for something to require it before
  > adding it though?
  >
  >
  > On Sat, Jul 19, 2014 at 11:41 PM, joehuang <joehu...@huawei.com> wrote:
  >
  > >  Hello, Kevin
  > >
  > >
  > >
  > > The leakage risk may be one of the design purpose. But  Nova/Cinder
  has
  > > already stored the token into the context, because Nova needs to
  access
  > > Neutron.Cinder.Glance, And Cinder interact with Glance....
  > >
  > >
  > >
  > > For Neutron, I think why the token has not been passed to the
  context, is
  > > because that Neutron only reactively provide service (exactly PORT )
  to
  > > Nova currently, so Neutron has not call other services' API by using
  the
  > > token.
  > >
  > >
  > >
  > > If the underlying agent or plugin wants to use the token, then the
  > > requirement will be asked by somebody.
  > >
  > >
  > >
  > > BR
  > >
  > >
  > >
  > > Joe
  > >
  > >
  > >  ------------------------------
  > > *???件人:* Kevin Benton [blak...@gmail.com]
  > > *???送??????:* 2014年7月19日 4:23
  > >
  > > *收件人:* OpenStack Development Mailing List (not for usage
  questions)
  > > *主???:* Re: [openstack-dev] [Neutron] Auth token in context
  > >
  > >   I suspect it was just excluded since it is authenticating
  information
  > > and there wasn't a good use case to pass it around everywhere in the
  > > context where it might be leaked into logs or other network requests
  > > unexpectedly.
  > >
  > >
  > > On Fri, Jul 18, 2014 at 1:10 PM, Phillip Toohill <
  > > phillip.tooh...@rackspace.com> wrote:
  > >
  > >>  It was for more of a potential use to query another service. Don't
  > >> think well go this route though, but was curious why it was one of
  the only
  > >> values not populated even though there's a field for it.
  > >>
  > >>   From: Kevin Benton <blak...@gmail.com>
  > >> Reply-To: "OpenStack Development Mailing List (not for usage
  questions)"
  > >> <openstack-dev@lists.openstack.org>
  > >> Date: Friday, July 18, 2014 2:16 PM
  > >> To: "OpenStack Development Mailing List (not for usage questions)" <
  > >> openstack-dev@lists.openstack.org>
  > >> Subject: Re: [openstack-dev] [Neutron] Auth token in context
  > >>
  > >>   What are you trying to use the token to do?
  > >>
  > >>
  > >> On Fri, Jul 18, 2014 at 9:16 AM, Phillip Toohill <
  > >> phillip.tooh...@rackspace.com> wrote:
  > >>
  > >>> Excellent! Thank you for the response, I figured it was possible,
  just
  > >>> concerned me to why everything else made it to context except for
  the
  > >>> token.
  > >>>
  > >>> So to be clear, you agree that it should at least be passed to
  context
  > >>> and
  > >>> because its not could be deemed a bug?
  > >>>
  > >>> Thank you
  > >>>
  > >>> On 7/18/14 2:03 AM, "joehuang" <joehu...@huawei.com> wrote:
  > >>>
  > >>> >Hello, Phillip.
  > >>> >
  > >>> >Currently, Neutron did not pass the token to the context. But
  > >>> Nova/Cinder
  > >>> >did that. It's easy to do that, just 'copy' from Nova/Cinder.
  > >>> >
  > >>> >1.  How Nova/Cinder did that
  > >>> >class NovaKeystoneContext(wsgi.Middleware)
  > >>> >///or CinderKeystoneContext for cinder
  > >>> >
  > >>> >              auth_token = req.headers.get('X_AUTH_TOKEN',
  > >>> >                                     req.headers.get
  ('X_STORAGE_TOKEN'))
  > >>> >              ctx = context.RequestContext(user_id,
  > >>> >                                     project_id,
  > >>> >                                     user_name=user_name,
  > >>> >                                     project_name=project_name,
  > >>> >                                     roles=roles,
  > >>> >                                     auth_token=auth_token,
  > >>> >
  remote_address=remote_address,
  > >>> >
  service_catalog=service_catalog)
  > >>> >
  > >>> >2.  Neutron not passed token. Also not good for the third part
  network
  > >>> >infrastructure to integrate the authentication with KeyStone.
  > >>> >class NeutronKeystoneContext(wsgi.Middleware)
  > >>> >.................
  > >>> >##### token not get from the header and not passed to context.
  Just
  > >>> >change here like what Nova/Cinder did.
  > >>> >        context.Context(user_id, tenant_id, roles=roles,
  > >>> >                              user_name=user_name,
  > >>> >tenant_name=tenant_name,
  > >>> >                              request_id=req_id)
  > >>> >        req.environ['neutron.context'] = ctx
  > >>> >
  > >>> >I think I'd better to report a bug for your case.
  > >>> >
  > >>> >Best Regards
  > >>> >Chaoyi Huang ( Joe Huang )
  > >>> >-----???件原件-----
  > >>> >???件人: Phillip Toohill [mailto:phillip.tooh...@rackspace.com]
  > >>> >???送??????: 2014年7月18日 14:07
  > >>> >收件人: OpenStack Development Mailing List (not for usage
  questions)
  > >>> >主???: [openstack-dev] [Neutron] Auth token in context
  > >>> >
  > >>> >Hello all,
  > >>> >
  > >>> >I am wondering how to get the auth token from a user request
  passed down
  > >>> >to the context so it can potentially be used by the plugin or
  driver?
  > >>> >
  > >>> >Thank you
  > >>> >
  > >>> >
  > >>> >_______________________________________________
  > >>> >OpenStack-dev mailing list
  > >>> >OpenStack-dev@lists.openstack.org
  > >>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  > >>> >_______________________________________________
  > >>> >OpenStack-dev mailing list
  > >>> >OpenStack-dev@lists.openstack.org
  > >>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  > >>>
  > >>> _______________________________________________
  > >>> OpenStack-dev mailing list
  > >>> OpenStack-dev@lists.openstack.org
  > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  > >>>
  > >>
  > >>
  > >>
  > >>  --
  > >> Kevin Benton
  > >>
  > >> _______________________________________________
  > >> OpenStack-dev mailing list
  > >> OpenStack-dev@lists.openstack.org
  > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  > >>
  > >>
  > >
  > >
  > >  --
  > > Kevin Benton
  > >
  > > _______________________________________________
  > > OpenStack-dev mailing list
  > > OpenStack-dev@lists.openstack.org
  > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  > >
  > >
  >
  >
  > --
  > Kevin Benton

  > _______________________________________________
  > OpenStack-dev mailing list
  > OpenStack-dev@lists.openstack.org
  > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


  --
  Isaku Yamahata <isaku.yamah...@gmail.com>

  _______________________________________________
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Kevin Benton_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to