Open Stack

Tanks for your reply, do you mean that it is no need to verify this in neutron, IOW we could verify it in client side?


在 2014年2月17日，20:35，Yongsheng Gong <gongysh at unitedstack.com> 写道：

> It is not easy to enhance it. If we check the tenant_id on creation, if should we  also to do some job when keystone delete tenant?
> 
> 
> On Mon, Feb 17, 2014 at 6:41 AM, Dolph Mathews <dolph.mathews at gmail.com> wrote:
> keystoneclient.middlware.auth_token passes a project ID (and name, for convenience) to the underlying application through the WSGI environment, and already ensures that this value can not be manipulated by the end user.
> 
> Project ID's (redundantly) passed through other means, such as URLs, are up to the service to independently verify against keystone (or equivalently, against the WSGI environment), but can be directly manipulated by the end user if no checks are in place.
> 
> Without auth_token in place to manage multitenant authorization, I'd still expect services to blindly trust the values provided in the environment (useful for both debugging the service and alternative deployment architectures).
> 
> On Sun, Feb 16, 2014 at 8:52 AM, Dong Liu <willowd878 at gmail.com> wrote:
> Hi stackers:
> 
> I found that when creating network subnet and other resources, the attribute tenant_id
> can be set by admin tenant. But we did not verify that if the tanent_id is real in keystone.
> 
> I know that we could use neutron without keystone, but do you think tenant_id should
> be verified when we using neutron with keystone.
> 
> thanks
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140218/a38b8d50/attachment.html>