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