Question Can you pls tell the reson for this behaviour change

Hi,
Please tell us why the below code snippet is not working with 11.3 . 10.2B It works fine.
Code:
FIND _user WHERE _user._userid = ipassword EXCLUSIVE-LOCK. This fails in 11.3 .
Any clues will help .

DEFINE VARIABLE cUser  AS CHARACTER   NO-UNDO.
CREATE _user.
ASSIGN
    _user._userid = "someuser"
    _user._user-name = "someuser".


cUser  = _user._userid.
RUN checkpass.p(INPUT cUser).

/* checkpass.p */
DEFINE INPUT PARAMETER ipassword AS CHAR NO-UNDO.
FIND  _user WHERE _user._userid = ipassword EXCLUSIVE-LOCK.
ASSIGN
  _user._password = "somepasword".

-Philip-
 
Last edited by a moderator:

Cringer

ProgressTalk.com Moderator
Staff member
What errors are you getting. Are you sure there is just one user with that password?

Try

IF NOT AVAILABLE _user THEN
MESSAGE AMBIGUOUS(_user).
 
Yes . Only one userwith that password.
Since the FIND fails in 11.3 in the procedure checkpass.p

FIND _user WHERE _user._userid = ipassword EXCLUSIVE-LOCK.

We are getting the error "Unable to update _user".

-Philip-
 

Cringer

ProgressTalk.com Moderator
Staff member
Sounds like a permissions thing. I'm not sure how the security works as we have our own system so I'll let someone else reply who knows, but I believe you have to have the rights to update users.
 

TheMadDBA

Active Member
Are you sure it actually works in 10.2B? It just silently errors out without assigning the password for me.

We have always had to remove/recreate the user to change the password as far back as I can remember.
 
It is assging the new password from checkpass.p and
if I display , it shows the password as somepasword in 10.2B

FOR EACH _user WHERE _user._userid = "someuser":
DISP
_user._password.
END.
 

TomBascom

Curmudgeon
What error does it fail with? Specific error messages and the actual text of the message are always helpful when claiming that something does not work...

The code snippet is terrible on any number of fronts and a great deal will depend on the context in which it is really being run. Particularly due to point #2 below. But point #3 could also be critical depending on what the real code that really has a problem really does.

Some of the things that I do not like about the code:

0) Keywords are UPPER-CASED in the style of the Progress documentation.

1) The code follows the execrable counter-productive practice of "hungarian notation" prefixing gibberish onto perfectly good variable names for no reason and to no benefit.

2) Record, lock and transaction scope are uncontrolled and global.

3) A parameter is defined ("ipassword") with a name that is completely deceptive and used for another purpose completely (as the userid key) while the apparent function of the parameter is then fulfilled by a constant. (And this in a code snippet that uses hungarian notation which is supposedly all about making it clear about what things are...)

4) The procedure has no RETURN.

Best practice when changing passwords has *always* been to delete and recreate the record and to assign the password along with the userid in a single ASSIGN statement in a strong scoped block. Like this:

Code:
/* usermaint.p
*/

define variable id  as character no-undo.
define variable name  as character no-undo.
define variable password as character no-undo.

procedure changePassword:

  define input parameter usrId  as character no-undo.
  define input parameter usrName  as character no-undo.
  define input parameter usrPassword as character no-undo.

  define buffer curr_user for _user.
  define buffer upd_user  for _user.

  define variable ok as logical no-undo.

  /* this really ought to check that ENCODE( usrPassword ) = _user._password
  */

  find curr_user no-lock where curr_user._userid = usrId no-error.
  if available curr_user then
  ok = yes.

  do for upd_user transaction.

  find upd_user exclusive-lock where recid( upd_user ) = recid( curr_user ) no-error.

  if available upd_user then
  delete upd_user.

  create upd_user.
  assign
  upd_user._userid  = usrId
  upd_user._user-name = usrName
  upd_user._password  = usrPassword
  upd_user._user-misc = ( if ok then "old" else "new" )
  .

  end.

  return.

end.

update
  id  skip
  name  skip
  password  skip
with
  frame get_user
  side-labels
  1 column
.

run changePassword( id, name, password ).

find _user no-lock where _user._userid = id no-error.
display _user with side-labels 1 column frame show_user.

If your code didn't do that and has worked in the past it is almost certainly accidental.

If it is breaking in 11.3 I would expect that that is because Progress has, over time, been plugging holes in the security model and whatever bug was accidentally allowing your old code to work has been fixed. Without knowing the actual error message and the real circumstances under which your code was running it is difficult to say more.
 
Top