Hi Rick,
I have a weird one. When I deploy my WWWC App, I have noticed the LogonCount and LastOn columns are not updated. I also noticed that when I set Active = .F., it makes no difference. It seems to work perfectly on my development machine. Any ideas?

TIA,
Steve

That sounds like an issue with the data access not writing the meta data. Make sure the DB structure is the same between local and live and not silently failing.

I don't think that this would silently fail though, so not sure what's different.

+++ Rick ---

Thanks Rick. Still stumped.

I copied the UserSecurity files from dev to the deployed site as a test. It still fails. The odd thing is, once in a while it updates Laston and LogonCount. I'll keep digging.

TIA,
Steve

Finally had a chance to look at the code. There's only one place where the LogonCount is updated which is in the Authenticate method.

If your authentication works (ie. it returns true) then the count should be updated. If it isn't it's possible that the SaveUser() method is not working on your server due to some configuration issue perhaps?

*** Now that we have the user update his stats
THIS.ouser.laston = DATETIME()
THIS.ouser.logoncount = THIS.ouser.logoncount + 1

IF !EMPTY(this.cPasswordEncryptionKey) AND !EndsWith(this.oUser.Password,"~~")
   this.ouser.password = this.GetPasswordHash(this.oUser.Password)
endif

TRY
   *** New feature so bracket
   THIS.oUser.Validate = ""
CATCH
ENDTRY

*** And save the changes
THIS.SaveUser()

RETURN .T.

Note that the code explicitly ignores the SaveUser() return value because it's more of a convenience feature than the actual auth behavior, so Auth can work and succeed but perhaps not update the data.

If you're using Fox tables - perhaps there's some permissions issue that doesn't allow updating the table? Make sure the IIS Identity for your Application Pool can read and write tables in the folder that usersecurity.dbf exists.

+++ Rick ---

Thanks Rick! I will follow your hints and let you know.

Steve

Hi Rick,
OK! This turned out to be passwords less than 6 chars. This latest website I am working on is still in test mode and I was using 4 character passwords entered directly into the usersecurity table. This morning, I decided to take a closer look at the wwusersecurity.prg class and the nMinPasswordLength property caught my eye. As a test, I changed the password to 8 characters, and the LastOn and LogonCount updates are now saved!

It was odd that on my dev box, the 4-character passwords were working. I looked at wwusersecurity.prg on my dev box and the .fxp was older, from 04/23/2025. So, perhaps the 6-character minimum password length was added after 04/23/2025 maybe?? Anyway, I recompiled wwusersecurity.prg on my dev box and the 4-character passwords stopped working on my dev box as well, as I would expect. Mystery solved!!

Thanks Rick!

Hmmm... if that's the case the logon should have failed. If a logon fails obviously it's not counted, but it also shouldn't work and allow the user in 😄

As to code differences: Yeah when in doubt always make sure your code matches from dev to live. FWIW, you should probably compile your app into an EXE to avoid issues like file mismatches of FXP/PRG files.

+++ Rick ---

Well, the minimum password length check is in the SaveUser() method, and I don't think it has any affect on the Authenticate() function. So, if I'm reading the code correctly, a short password should not cause the logon to fail.

Thanks again!

Hmmm... that's a good point! That's not exactly optimal. But it's a bit of an edge case.

+++ Rick ---