[openstack-dev] [Oslo][oslo.messaging][all] Notice: upcoming change to oslo.messaging RPC server
ChangBo Guo
glongwave at gmail.com
Thu Sep 28 12:17:33 UTC 2017
BTW, We plan to release 5.33 with the patch https://review.openstack.org/#
/c/500456/ please let me know if you need hold the release.
[ Unreleased changes in openstack/oslo.messaging (master) ]
Changes between 5.32.0 and a9d10d3
* 3a9c01f 2017-09-24 20:25:38 -0700 Fix default value of RPC dispatcher
access_policy
| * 6efa86a 2017-09-22 17:13:26 -0700 Fix wrong transport warnings in
functional tests
|/
* c2338ee 2017-09-20 16:23:04 +0000 Updated from global requirements
2017-09-28 20:11 GMT+08:00 ChangBo Guo <glongwave at gmail.com>:
> Ken, thanks for raising this , Oslo team will send notice early when we
> have major changes like this .
>
> 2017-09-27 4:17 GMT+08:00 Ken Giusti <kgiusti at gmail.com>:
>
>> Hi Folks,
>>
>> Just a head's up:
>>
>> In Queens the default access policy for RPC Endpoints will change from
>> LegacyRPCAccessPolicy to DefaultRPCAccessPolicy. RPC calls to private
>> ('_' prefix) methods will no longer be possible. If you want to allow
>> RPC Clients to invoke private methods, you must explicitly set the
>> access_policy to LegacyRPCAccessPolicy when you call get_rpc_server()
>> or instantiate an RPCDispatcher. This change [0] has been merged to
>> oslo.messaging master and will appear in the next release of
>> oslo.messaging.
>>
>> "Umm.... What?"
>>
>> Good question! Here's the TL;DR details:
>>
>> Since forever it's been possible for a client to make an RPC call
>> against _any_ method defined in the RPC Endpoint object. And by "any"
>> we mean "all methods including private ones (method names prefixed by
>> '_' )"
>>
>> Naturally this ability came as a surprise many folk [1], including
>> yours truly and others on the oslo team [2]. It was agreed that
>> having this be the default behavior was indeed A Bad Thing.
>>
>> So starting in Ocata oslo.messaging has provided a means for
>> controlling access to Endpoint methods [3]. Oslo.messaging now
>> defines three different "access control policies" that can be applied
>> to an RPC Server:
>>
>> LegacyRPCAccessPolicy: original behavior - any method can be invoked
>> by an RPC client
>> DefaultRPCAccessPolicy: prevent RPC access to private '_' methods, all
>> others may be invoked
>> ExplicitRPCAccessPolicy: only allow access to those methods that have
>> been decorated with @expose decorator
>>
>> See [4] for more details.
>>
>> In order not to break anything at the time the default access policy
>> was set to 'LegacyRPCAccessPolicy'. This has been the default for
>> Ocata and Pike.
>>
>> Starting in Queens this will no longer be the case.
>> DefaultRPCAccessPolicy will become the default if no access policy is
>> specified when calling get_rpc_server() or directly instantiating an
>> RPCDispatcher. To keep the old behavior you must explicitly set the
>> access policy to LegacyRPCAccessPolicy:
>>
>> from oslo_messaging.rpc import LegacyRPCAccessPolicy
>> ...
>> server = get_rpc_server(transport, target, endpoints,
>> access_policy=LegacyRPCAccessPolicy)
>>
>>
>>
>> Reply here if you have any questions or hit any issues, thanks!
>>
>> -K
>>
>> [0] https://review.openstack.org/#/c/500456/
>> [1] https://bugs.launchpad.net/oslo.messaging/+bug/1194279
>> [2] https://bugs.launchpad.net/oslo.messaging/+bug/1555845
>> [3] https://review.openstack.org/#/c/358359/
>> [4] https://docs.openstack.org/oslo.messaging/latest/reference/
>> server.html
>> --
>> Ken Giusti (kgiusti at gmail.com)
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> ChangBo Guo(gcb)
> Community Director @EasyStack
>
--
ChangBo Guo(gcb)
Community Director @EasyStack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170928/f96b385c/attachment.html>
More information about the OpenStack-dev
mailing list