Client-principal error - Forum - OpenEdge Development - Progress Community
 Forum

Client-principal error

This question has suggested answer(s)

Openedge 10.2B0710 

In my login screen of the application when the user presses the OK button (after filling out the password en username) , I create a client-principal object.  

All goes well, the sealing is OK, but when I try to set the client-principal to all connected databases I get an error 

Same problem with statement security-policy:set-client (vhCP) or with statement set-db-client(vhCp)

the error is Client-principal:authentication-faild error because object is sealed (14549) 

anyone an idea ? 

All Replies
  • Sounds like one or more of your databases tries to authenticate the principal against its own domain registry, rather than trusting the one that you sent.

    Check if the "Use application domain registry" option is switch on, or alternatively that the domain exists in the database with the same passkey.

    Simon L Prinsloo

    www.vidisolve.com

  • Should the domain exists in every connected database ?

  • A domain with the same domain name and the same domain access key must exist in each database where you are trying to assert the identity against. You do not need the user names, and you can use the _extsso authentication system (IIRC).
     
  • I loaded the domains in every connected database and the error is gone

    however when I change an auditing enabled record , the userid is blank in the auditing table

    I set the "use application user id" setting in the database options

  • apparently there is a difference between

    * security-policy:set-client (vhCP).

    * set-db-client (vhCP).

    the auditing user is only filled in with the first statement

  • There are two distinct aspects to CP - the setting for each DB and the setting for the session.  These values can be different, which is not immediately clear from the docs.

    set-db-client sets the CP for a single DB

    (I believe) security-policy:set-client sets it for the session *and* all connected DBs.

    If one of the db's does not have the corresponding domain / access code then it can reject the CP which is what I believe you're seeing.