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
Tagged:

Best Answer

  • zoya faberov
    zoya faberov ✭✭✭✭✭
    Answer ✓

    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.

Answers

  • kage.wu
    kage.wu Newcomer
    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,
  • kage.wu
    kage.wu Newcomer
    or give me a complete example on how to use dacsSubscribeClient to verify INTC.O
  • zoya faberov
    zoya faberov ✭✭✭✭✭

    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.