Andrew Johnson wrote:
Shouldn't a propertySurveyor also be given access rights information
(i.e. whether a particular property is writable or not)? Do you
intend to use a different mechanism to communicate that somehow?
Unfortunately your very clever template mechanism only works with
fully symmetrical property sets; in many cases I think we're going to
have to write all three traverse() routines ourselves, to cope with
read-only properties.
This is a really interesting issue - here's what I've been thinking:
To avoid loads of exception being thrown, the traverse methods should
only reveal properties that are appropriate for the traverse's use. The
viewer traverse should only reveal properties that are readable, the
manipulator traverse should only reveal things that are writable, the
surveyor traverse should reveal everything that's available including
the information if something is writeable.
This works so far, as DA only distinguishes between read-only and
read-write properties.
So - what are we doing with access rights that are based on AccessSecurity?
For V3, AccessSecurity stuff is spread through different layers:
- For the client, AccessSecurity change callbacks and the related stuff
are an integral part of ChannelAccess and its network protocol; access
rights info is closely coupled to the data
- The CA server does the client authentification (checks user and host name)
- A separate module (i.e., library) holds the AccessSecurity
configuration and does the on-line rule-based checks (including CALC
based rules that have other CA client connections)
- The database definition (dbd file) holds the AccessSecurity level info
per field (as part of the record definition)
- The database (db) holds the AccessSecurity group info per record
instance (as ASG field of record instance)
If we try to copy the functionality to V4 with the least changes in
structure and mechanisms, the service (EPICS database) will still have
to hold and provide AS level and group info to the server(s). These
would probably be implemented as properties in the record's views: Group
info as a top level property (or somewhere on record level), AS level
info as a subordinate property - for every property. (Is there a way to
make this easier?)
The server (in this case CA) will have to use that information and will
probably continue to use the checks of the AS library.
How will the AS info be connected to the property catalogs?
I see problems with Jeff's initial suggestion ("When implementing a
property catalog for an EPICS PV there may also need to be subordinate
properties for the access rights so that they might be dynamic."): A
property without read-access will disappear from the viewer-traverse -
and with it a subordinate property will simply go away. The client
subscribing to this sub-property will probably get a connection loss
exception thrown.
My favourite solution at the moment: (btw. I have been mentioning this
problem and my suggestion in several emails without reaction)
The access rights property is completely taken out of the data and the
CA server reveals it as part of the surveyor traverse. That way it is
assured that it always exists (even if read-access to the data is taken
away) and clients get updates for a subscription as they expect.
Ralph
Other question: Will we keep the same mechanisms for Access Security in
V4? Are there other techniques that should be implemented or at least
made feasible by defining appropriate AS plug-in APIs? What about the
user/password credentials (probably checked against an auth server) that
we saw at the ABB show? I liked that, admittedly. Is the AS group and
level info in the EPICS database generic enough to support other
security mechanisms?
- Replies:
- RE: ICE and TIPC Jeff Hill
- References:
- RE: ICE and TIPC Jeff Hill
- Re: ICE and TIPC Andrew Johnson
- Navigate by Date:
- Prev:
Re: next meeting before EPICS meeting at Archamps? Ralph Lange
- Next:
Re: DA / Generic Container Yard Ralph Lange
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: ICE and TIPC Jeff Hill
- Next:
RE: ICE and TIPC Jeff Hill
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|