[openstack-dev] 答???: [Neutron] Auth token in context
Mohammad Banikazemi
mb at us.ibm.com
Mon Aug 4 17:11:23 UTC 2014
Yes, Here: https://review.openstack.org/#/c/111756/
From: Kevin Benton <blak111 at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Cc: isaku.yamahata at 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.yamahata at 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 <blak111 at 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 <joehuang at 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 [blak111 at 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.toohill at 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 <blak111 at gmail.com>
> >> Reply-To: "OpenStack Development Mailing List (not for usage
questions)"
> >> <openstack-dev at lists.openstack.org>
> >> Date: Friday, July 18, 2014 2:16 PM
> >> To: "OpenStack Development Mailing List (not for usage questions)" <
> >> openstack-dev at 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.toohill at 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" <joehuang at 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.toohill at 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 at lists.openstack.org
> >>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>> >_______________________________________________
> >>> >OpenStack-dev mailing list
> >>> >OpenStack-dev at lists.openstack.org
> >>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>
> >> --
> >> Kevin Benton
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> >
> > --
> > Kevin Benton
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
>
>
> --
> Kevin Benton
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Isaku Yamahata <isaku.yamahata at gmail.com>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140804/329261d4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140804/329261d4/attachment.gif>
More information about the OpenStack-dev
mailing list
