How to read named password from User Application in workflow

Hi All,

I have a named password in User Application driver which I want to read in workflow to login to DB.

I have created a GCV with type password-ref and linked to named password like below.

<definition critical-change="true" display-name="Password" name="gcvDBPwd" type="password-ref">
<description/>
<value>npDBpwd</value>
</definition>

Also, I have enabled the GCV which allows reading named password.

<definition display-name="Allow Named Password to be retrieved over LDAP" name="allow-fetch-named-passwords" type="boolean">
<description>Allow Named Password to be retrieved over LDAP. If the
value is true, then the named password value can be fetched.</description>
<value>true</value>
</definition>


And now in mapping activity I tried to read the named password like below,

var dbPwd = GCV.getValueForNamedPassword('npDBpwd');


But I am getting a null value for dbPwd variable. Is there anything I missed here?
  • On 6/8/2018 1:44 AM, rajeshnaik wrote:
    >
    > Hi All,
    >
    > I have a named password in User Application driver which I want to read
    > in workflow to login to DB.
    >
    > *I have created a GCV with type password-ref and linked to named
    > password like below.*
    >
    > <definition critical-change="true" display-name="Password"
    > name="gcvDBPwd" type="password-ref">
    > <description/>
    > <value>npDBpwd</value>
    > </definition>
    >
    > *Also, I have enabled the GCV which allows reading named password.*
    >
    > <definition display-name="Allow Named Password to be retrieved over
    > LDAP" name="allow-fetch-named-passwords" type="boolean">
    > <description>Allow Named Password to be retrieved over LDAP. If the
    > value is true, then the named password value can be
    > fetched.</description>
    > <value>true</value>
    > </definition>
    >
    >
    > *And now in mapping activity I tried to read the named password like
    > below,*
    >
    > var dbPwd = GCV.getValueForNamedPassword('npDBpwd');
    >
    >
    > But I am getting a null value for dbPwd variable. Is there anything I
    > missed here?
    >
    >


    Restart User App driver if you haven't after these changes, then try
    using the name of the GCV-ref in your function call

    var dbPwd = GCV.getValueForNamedPassword('gcvDBPwd');

    Cheers,

    -Fernando
  • Fernando Freitas;2482244 wrote:
    On 6/8/2018 1:44 AM, rajeshnaik wrote:
    >
    > Hi All,
    >
    > I have a named password in User Application driver which I want to read
    > in workflow to login to DB.
    >
    > *I have created a GCV with type password-ref and linked to named
    > password like below.*
    >
    > <definition critical-change="true" display-name="Password"
    > name="gcvDBPwd" type="password-ref">
    > <description/>
    > <value>npDBpwd</value>
    > </definition>
    >
    > *Also, I have enabled the GCV which allows reading named password.*
    >
    > <definition display-name="Allow Named Password to be retrieved over
    > LDAP" name="allow-fetch-named-passwords" type="boolean">
    > <description>Allow Named Password to be retrieved over LDAP. If the
    > value is true, then the named password value can be
    > fetched.</description>
    > <value>true</value>
    > </definition>
    >
    >
    > *And now in mapping activity I tried to read the named password like
    > below,*
    >
    > var dbPwd = GCV.getValueForNamedPassword('npDBpwd');
    >
    >
    > But I am getting a null value for dbPwd variable. Is there anything I
    > missed here?
    >
    >


    Restart User App driver if you haven't after these changes, then try
    using the name of the GCV-ref in your function call

    var dbPwd = GCV.getValueForNamedPassword('gcvDBPwd');

    Cheers,

    -Fernando








    Thanks a ton Fernando :) When I expand the GCVs in my ecmascript builder, It was automatically posting named password key instaed of gcv key. Once again thank you!
  • > Thanks a ton Fernando :) When I expand the GCVs in my ecmascript
    > builder, It was automatically posting named password key instaed of gcv
    > key. Once again thank you!


    It is a bit odd, since the API to read a GCV is different from a Named
    Password, but they decided to use GCV's and then make a special case of
    GCV for a Named Password, rather than just directly supporting Named
    Passwords. Design choices made a while back, sort of annoying but you
    just live with them.


  • On 08.06.18 16:27, Geoffrey Carman wrote:
    >> Thanks a ton Fernando :) When I expand the GCVs in my ecmascript
    >> builder, It was automatically posting named password key instaed of gcv
    >> key. Once again thank you!

    >
    > It is a bit odd, since the API to read a GCV is different from a Named
    > Password, but they decided to use GCV's and then make a special case of
    > GCV for a Named Password, rather than just directly supporting Named
    > Passwords.  Design choices made a while back, sort of annoying butyou
    > just live with them.
    >
    >

    I am not sure I can follow your argumentation, could you please elaborate?


    Casper

  • On 6/8/2018 10:40 AM, Casper Pedersen wrote:
    > On 08.06.18 16:27, Geoffrey Carman wrote:
    >>> Thanks a ton Fernando :) When I expand the GCVs in my ecmascript
    >>> builder, It was automatically posting named password key instaed of gcv
    >>> key. Once again thank you!

    >>
    >> It is a bit odd, since the API to read a GCV is different from a Named
    >> Password, but they decided to use GCV's and then make a special case
    >> of GCV for a Named Password, rather than just directly supporting
    >> Named Passwords.  Design choices made a while back, sort of annoying
    >> but you just live with them.
    >>
    >>

    > I am not sure I can follow your argumentation, could you please elaborate?


    Why does the function call, GCV.getValueForNamedPassword() require NOT
    the named password name, but the GCV that refernces the Named Password?
    I was trying to explain some of the history of how we got there.


  • On 08.06.18 17:07, Geoffrey Carman wrote:
    > On 6/8/2018 10:40 AM, Casper Pedersen wrote:
    >> On 08.06.18 16:27, Geoffrey Carman wrote:
    >>>> Thanks a ton Fernando :) When I expand the GCVs in my ecmascript
    >>>> builder, It was automatically posting named password key instaed of gcv
    >>>> key. Once again thank you!
    >>>
    >>> It is a bit odd, since the API to read a GCV is different from a
    >>> Named Password, but they decided to use GCV's and then make a special
    >>> case of GCV for a Named Password, rather than just directly
    >>> supporting Named Passwords.  Design choices made a while back, sort
    >>> of annoying but you just live with them.
    >>>
    >>>

    >> I am not sure I can follow your argumentation, could you please
    >> elaborate?

    >
    > Why does the function call, GCV.getValueForNamedPassword() require NOT
    > the named password name, but the GCV that refernces the Named Password?
    > I was trying to explain some of the history of how we got there.


    Now I get it, thanks. I've also been thinking about it; there must have
    been a good reason for doing so, back in the day when it was
    implemented, that is what I could come up with.

    Casper


  • On 6/11/2018 2:27 AM, Casper Pedersen wrote:
    > On 08.06.18 17:07, Geoffrey Carman wrote:
    >> On 6/8/2018 10:40 AM, Casper Pedersen wrote:
    >>> On 08.06.18 16:27, Geoffrey Carman wrote:
    >>>>> Thanks a ton Fernando :) When I expand the GCVs in my ecmascript
    >>>>> builder, It was automatically posting named password key instaed of
    >>>>> gcv
    >>>>> key. Once again thank you!
    >>>>
    >>>> It is a bit odd, since the API to read a GCV is different from a
    >>>> Named Password, but they decided to use GCV's and then make a
    >>>> special case of GCV for a Named Password, rather than just directly
    >>>> supporting Named Passwords.  Design choices made a while back, sort
    >>>> of annoying but you just live with them.
    >>>>
    >>>>
    >>> I am not sure I can follow your argumentation, could you please
    >>> elaborate?

    >>
    >> Why does the function call, GCV.getValueForNamedPassword() require NOT
    >> the named password name, but the GCV that refernces the Named
    >> Password? I was trying to explain some of the history of how we got
    >> there.

    >
    > Now I get it, thanks. I've also been thinking about it; there must have
    > been a good reason for doing so, back in the day when it was
    > implemented, that is what I could come up with.


    I like understanding the WHY things are done in unexpected ways. If you
    ever worked with Lotus Notes, fresh, then you spend all day saying, I
    see what you did there, but WHY, why why would you ever do it that way? :)


  • On 11.06.18 15:47, Geoffrey Carman wrote:
    > On 6/11/2018 2:27 AM, Casper Pedersen wrote:
    >> On 08.06.18 17:07, Geoffrey Carman wrote:
    >>> On 6/8/2018 10:40 AM, Casper Pedersen wrote:
    >>>> On 08.06.18 16:27, Geoffrey Carman wrote:
    >>>>>> Thanks a ton Fernando :) When I expand the GCVs in my ecmascript
    >>>>>> builder, It was automatically posting named password key instaed
    >>>>>> of gcv
    >>>>>> key. Once again thank you!
    >>>>>
    >>>>> It is a bit odd, since the API to read a GCV is different from a
    >>>>> Named Password, but they decided to use GCV's and then make a
    >>>>> special case of GCV for a Named Password, rather than just directly
    >>>>> supporting Named Passwords.  Design choices made a while back,sort
    >>>>> of annoying but you just live with them.
    >>>>>
    >>>>>
    >>>> I am not sure I can follow your argumentation, could you please
    >>>> elaborate?
    >>>
    >>> Why does the function call, GCV.getValueForNamedPassword() require
    >>> NOT the named password name, but the GCV that refernces the Named
    >>> Password? I was trying to explain some of the history of how we got
    >>> there.

    >>
    >> Now I get it, thanks. I've also been thinking about it; there must
    >> have been a good reason for doing so, back in the day when it was
    >> implemented, that is what I could come up with.

    >
    > I like understanding the WHY things are done in unexpected ways. If you
    > ever worked with Lotus Notes, fresh, then you spend all day saying, I
    > see what you did there, but WHY, why why would you ever do it that way?  :)
    >
    >

    Be nice, talking about Notes ruins my morning coffee... :-)

    The problem with software development is that at the point in time where
    it was implemented it was done right ... 10 years later people are
    shaking their heard.

    But I suspect I know why they are using the password-ref's - I am not
    100% sure, but the listNamedPasswords function might not be that old,
    which means that the only way they could browse the named passwords was
    by using the password-ref.



    Casper

  • On 6/12/2018 3:20 AM, Casper Pedersen wrote:
    > On 11.06.18 15:47, Geoffrey Carman wrote:
    >> On 6/11/2018 2:27 AM, Casper Pedersen wrote:
    >>> On 08.06.18 17:07, Geoffrey Carman wrote:
    >>>> On 6/8/2018 10:40 AM, Casper Pedersen wrote:
    >>>>> On 08.06.18 16:27, Geoffrey Carman wrote:
    >>>>>>> Thanks a ton Fernando :) When I expand the GCVs in my ecmascript
    >>>>>>> builder, It was automatically posting named password key instaed
    >>>>>>> of gcv
    >>>>>>> key. Once again thank you!
    >>>>>>
    >>>>>> It is a bit odd, since the API to read a GCV is different from a
    >>>>>> Named Password, but they decided to use GCV's and then make a
    >>>>>> special case of GCV for a Named Password, rather than just
    >>>>>> directly supporting Named Passwords.  Design choices made a while
    >>>>>> back, sort of annoying but you just live with them.
    >>>>>>
    >>>>>>
    >>>>> I am not sure I can follow your argumentation, could you please
    >>>>> elaborate?
    >>>>
    >>>> Why does the function call, GCV.getValueForNamedPassword() require
    >>>> NOT the named password name, but the GCV that refernces the Named
    >>>> Password? I was trying to explain some of the history of how we got
    >>>> there.
    >>>
    >>> Now I get it, thanks. I've also been thinking about it; there must
    >>> have been a good reason for doing so, back in the day when it was
    >>> implemented, that is what I could come up with.

    >>
    >> I like understanding the WHY things are done in unexpected ways. If
    >> you ever worked with Lotus Notes, fresh, then you spend all day
    >> saying, I see what you did there, but WHY, why why would you ever do
    >> it that way?  :)
    >>
    >>

    > Be nice, talking about Notes ruins my morning coffee... :-)


    So you know what I mean. :)

    > The problem with software development is that at the point in time where
    > it was implemented it was done right ... 10 years later people are
    > shaking their heard.


    I accept that reality, which I why I wonder at the logic from the time
    it was written. There is usually an interesting reason.


    > But I suspect I know why they are using the password-ref's - I am not
    > 100% sure, but the listNamedPasswords function might not be that old,
    > which means that the only way they could browse the named passwords was
    > by using the password-ref.


    You think so Designer can retrieve the list for its GUI? Interesting.

  • On 12.06.18 12:05, Geoffrey Carman wrote:
    > On 6/12/2018 3:20 AM, Casper Pedersen wrote:
    >> On 11.06.18 15:47, Geoffrey Carman wrote:
    >>> On 6/11/2018 2:27 AM, Casper Pedersen wrote:
    >>>> On 08.06.18 17:07, Geoffrey Carman wrote:
    >>>>> On 6/8/2018 10:40 AM, Casper Pedersen wrote:
    >>>>>> On 08.06.18 16:27, Geoffrey Carman wrote:
    >>>>>>>> Thanks a ton Fernando :) When I expand the GCVs in my ecmascript
    >>>>>>>> builder, It was automatically posting named password key instaed
    >>>>>>>> of gcv
    >>>>>>>> key. Once again thank you!
    >>>>>>>
    >>>>>>> It is a bit odd, since the API to read a GCV is different from a
    >>>>>>> Named Password, but they decided to use GCV's and then make a
    >>>>>>> special case of GCV for a Named Password, rather than just
    >>>>>>> directly supporting Named Passwords.  Design choices made a while
    >>>>>>> back, sort of annoying but you just live with them.
    >>>>>>>
    >>>>>>>
    >>>>>> I am not sure I can follow your argumentation, could you please
    >>>>>> elaborate?
    >>>>>
    >>>>> Why does the function call, GCV.getValueForNamedPassword() require
    >>>>> NOT the named password name, but the GCV that refernces the Named
    >>>>> Password? I was trying to explain some of the history of how we got
    >>>>> there.
    >>>>
    >>>> Now I get it, thanks. I've also been thinking about it; there must
    >>>> have been a good reason for doing so, back in the day when it was
    >>>> implemented, that is what I could come up with.
    >>>
    >>> I like understanding the WHY things are done in unexpected ways. If
    >>> you ever worked with Lotus Notes, fresh, then you spend all day
    >>> saying, I see what you did there, but WHY, why why would you ever do
    >>> it that way?  :)
    >>>
    >>>

    >> Be nice, talking about Notes ruins my morning coffee... :-)

    >
    > So you know what I mean.  :)
    >
    >> The problem with software development is that at the point in time
    >> where it was implemented it was done right ... 10 years later people
    >> are shaking their heard.

    >
    > I accept that reality, which I why I wonder at the logic from the time
    > it was written.  There is usually an interesting reason.
    >
    >
    >> But I suspect I know why they are using the password-ref's - I am not
    >> 100% sure, but the listNamedPasswords function might not be that old,
    >> which means that the only way they could browse the named passwords
    >> was by using the password-ref.

    >
    > You think so Designer can retrieve the list for its GUI?  Interesting.


    When I use the "Browse named passwords" next to the Password Named, when
    you use the token-named-password in a driver then it will list the named
    passwords.

    The "limitation" is with UserApp(Workflows) where it needs the
    password-ref, which I think is a limitation from way back when it was
    implemented. Ie. they where not able to "browse" named passwords
    directly and had to use the password-ref, which then resulted in the
    GCV.getValueForNamedPassword.


    But I really don't know why.


    Casper