1
●0 ●0 ●1
how to verify user permision and rics permission by the given user
Hi, I have asked the similar question before. Problem is that I can't reply your answer, to continue what I need to ask. On ./dacsSubscribeClient -D narvlii02156.xmp.net.intra:8211 -S IDN_SELECTFEED -u wuk -p 10.111.166.82/net -a 304 -i INTC.O I can verify userID, wuk is a valid user. Does it mean also INTC.O valid for userID wuk? since I put something garbage I still have the valid answer. e.g. ./dacsSubscribeClient -D narvlii02156.xmp.net.intra:8211 -S IDN_SELECTFEED -u wuk -p 10.111.166.82/net -a 304 -i foou [narvlii02156.xmp.net.intra:8211] Daemon connection state is UP [narvlii02156.xmp.net.intra:8211] Daemon connection opened [narvlii02156.xmp.net.intra:8211] wuk logged in [narvlii02156.xmp.net.intra:8211] Subscriber has been logged in [narvlii02156.xmp.net.intra:8211] wuk allowed access item name foou [narvlii02156.xmp.net.intra:8211] wuk logged out
23k
●22 ●9 ●14
Hello @kage.wu,
Believe the behavior is as expected, as IDN_SELECTFEED (usually aliased from ELEKTRON) is a content-case service, so a lock is required as input, to check content-based service permissions.
The usage should be:
dacsSubscribeClient [-D dacs_daemon] -S service_name -u username [-p position] [-a appID] [-L log_level] [-T wait_time] [-i item_name] pe1 [pe2 [peN]]
From the list of PEs a dacs lock is going to be generated, that will allow to check subscription on a content-based service.
Please see this previous discussion thread for additional details.
1
●0 ●0 ●1
can you give an example how to use pe1pe2... on ./dacsSubscribeClient -D narvlii02156.xmp.net.intra:8211 -S IDN_SELECTFEED -u wuk -p 10.111.166.82/net -a 304 -i INTC.O @zoya.farberov It will save me time. Thanks,
23k
●22 ●9 ●14
Hello @kage.wu,
As Permission Entity for INTC.O is 74, the correct check, under certain assumptions, should be
dacsSubscribeClient -D narvlii02156.xmp.net.intra:8211 -S IDN_SELECTFEED -u wuk -p 10.111.166.82/net -a 304 -i INTC.O 74
You should see:
allowed access item name INTC.O , PE 74
However:
1. OpenDACS API is a view into DACS, DACS is a complex system, and if in your local DACS the definition in DACS is not exactly as we expect, then the result via OpenDACS will be different as well. In this case, consult with your local DACS admin/group and find out what is defined within your local DACS and consequently, what to expect on the check.
2. Item name is not mandatory for this example usage, what is being checked is Permssion Enttity within DACS, i.e.
dacsSubscribeClient -D narvlii02156.xmp.net.intra:8211 -S IDN_SELECTFEED -u wuk -p 10.111.166.82/net -a 304 74
will also be true (assuming the definition for your user in DACS is as we expect it.
While
... -i INTC.O 75
Will be
denied access item name INTC.O , PE 75
that is, if your user is not permissioned for PE = 75. if the user is permissioned, it will be allowed.
In my opinion, OpenDACS API usage is so closely related to DACS definitions, that one can not proceed on integration and design without OpenDACS without knowing exactly what is defined in DACS at every step.
