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 <gong...@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.math...@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 <willowd...@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@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
