4.31 - WRDAuth

[Wouter Hendriks]

Re:

```

Various WRDAuth deprecations and removals to make room for 2FA support, contact us if you need any of these APIs:

• Removes the following APIs from wrdauth: ProcessPasswordReset, ProcessPasswordResetPost, CreateEmailVerificationLink, HandleEmailVerificationPage, HandleEmailVerificationData, UpdateUserAccountFields, UpdateUserPassword, GetWRDAuthConfig, PrepareMail

```

I currently have 5 active projects that are using CreateEmailVerificationLink and HandleEmailVerificationPage/Data, and was just beginning to add a 6th. 

Don't know what the options are but I'd very much very like to keep using these functions for a while.

For said 6th project I can of course use new code, which leads me to the question "which code should I use?"

[Arnold Hendriks]

```

Various WRDAuth deprecations and removals to make room for 2FA support, contact us if you need any of these APIs:

• Removes the following APIs from wrdauth: ProcessPasswordReset, ProcessPasswordResetPost, CreateEmailVerificationLink, HandleEmailVerificationPage, HandleEmailVerificationData, UpdateUserAccountFields, UpdateUserPassword, GetWRDAuthConfig, PrepareMail

```

I currently have 5 active projects that are using CreateEmailVerificationLink and HandleEmailVerificationPage/Data, and was just beginning to add a 6th. 

The APIs internally aren't that complex:

https://gitlab.com/webhare/platform/-/blob/release/4.30/whtree/modules/wrd/lib/internal/auth/legacy-api.whlib#L1149 

You could copy those two to your own code, replacing EncryptData with EncryptForThisServer and DecryptData similarly. 

You should also consider whether the verifier is strong enough for your purposes and/or you need any form of rate limiting (important policy aspects which are not supported through this route), and whether you need to take any measure to prevent reuse of the link after its first use (which is an issue with the current email verification flows which we're working on fixing, but can't be done in the current setup, especially not with <password> fields) 

 

Don't know what the options are but I'd very much very like to keep using these functions for a while.

For said 6th project I can of course use new code, which leads me to the question "which code should I use?"

Depends completely on what you're actually trying to build of course. CreateEmailVerificationLink and HandleEmailVerificationData are actually weird APIs in wrdauth, as nothing they do really requires the wrdauth instance. It only uses wrdauth for Encrypt/DecryptData. If it weren't for those two calls, they could have just been global functions in any whlib

 

 

[Wouter Hendriks]

The APIs internally aren't that complex:

https://gitlab.com/webhare/platform/-/blob/release/4.30/whtree/modules/wrd/lib/internal/auth/legacy-api.whlib#L1149 

You could copy those two to your own code, replacing EncryptData with EncryptForThisServer and DecryptData similarly. 

Okay, I'll look into that.

  

Don't know what the options are but I'd very much very like to keep using these functions for a while.

For said 6th project I can of course use new code, which leads me to the question "which code should I use?"

Depends completely on what you're actually trying to build of course.

Well, in this case the backend application should provide the user with a link to (re)set password (to be copy/pasted in an (own) e-mail sent to the client). How would you implement this in WebHare now? Is it even possible?

As described in https://www.webhare.dev/reference/wrdauth/authpages? (GetWRDAuthRouterWittyData)

 

[Arnold Hendriks]

For said 6th project I can of course use new code, which leads me to the question "which code should I use?"

Depends completely on what you're actually trying to build of course.

Well, in this case the backend application should provide the user with a link to (re)set password (to be copy/pasted in an (own) e-mail sent to the client). How would you implement this in WebHare now? Is it even possible?

As described in https://www.webhare.dev/reference/wrdauth/authpages? (GetWRDAuthRouterWittyData)

HandleForgotPassword in the wrdauthplugin, and look at how it invokes CreatePasswordResetLink. Which i forgot to mention, some of these APIs are now available on the plugin itself, so it may look like what you were using after all. 

Most of this restructuring is to get you away from using lowlevel auth objects or directly relying on the existence of wrd_authdomain(s) so we can refactor the lowlevel code (which is still architected after weblets etc, or lacks configurability)

[Wouter Hendriks]

Implementing now using GetWRDAuthPages, so far so good.

One question: my WRD login object contains an extra attribute that needs to be `TRUE` when logging in, is there a way to add an extra check/function during login, now that `supportobjectname` / `EXTEND WRDAuthSupportBase` is no longer possible?

[Arnold Hendriks]

WRDAuthSupportBase isn't going anywhere, it may be in legacy-api.whlib for technical reasons but it's available through mod::wrd/lib/auth.whlib

[Wouter Hendriks]

Hmm, thought that one would become deprecated, since I had to change code earlier to keep supporting the master password functionality (in a now removed forum.webhare.dev post)

[Wouter Hendriks]

Ah, that was because of this in https://groups.google.com/a/webhare.dev/g/announce/c/FpMA3AzTTWs:

> "Support for wrdauth plugins overriding VerifyPassword has been removed"

Should I override `IsLoginDenied` if I want add an extra login check?

[Arnold Hendriks]

I'd guess so. It's how tollium implements userlocking

PUBLIC STATIC OBJECTTYPE TolliumWRDAuthSupport EXTEND WRDAuthSupportBase

<

  UPDATE PUBLIC RECORD FUNCTION IsLoginDenied(INTEGER userid, RECORD options)

  {

    RECORD userinfo := this->plugin->accounttype->GetEntityFields(userid, ["WHUSER_DISABLED"]);

    IF(userinfo.whuser_disabled)

      RETURN [ code := "DISABLED" ];

    RETURN DEFAULT RECORD;

  }

>;