Password woes

rocketman

So, I'm still on V8.1. In the past month I've had an incredible number of users complaining they can't log in, getting "Invalid Credentials or Access denied". I'm struggling to understand how this can be. It can't all be down to a long Covid Layoff? - in fact I know it can't because some regular users including some admin staff with a high access level who use the system daily have had it happen to them several time over a few days.

Someone resets their password, they regain access for a couple of days then the password goes pop again and they need another reset.

So I'm thinking - is the password really going pop or is one or more of the main browsers doing something differently with their password storage/auto fill?. I use chrome on my main PC and for testing purposes, log in on iPad 4 (Safari) and iPhone 7 (Safari) and it's never happened to me

The only thing that has changed in my code that might have an impact is a "Mobile View" button on the main Desktop menu so that SOME Android users who log in using their phones and for some strange reason don't get the mobile screens can easily get to the mobile vies. The button simply calls a different (mobile) VP.

Any thoughts?

ACDC

Do you have any grouped object set with users i.e. more than one object handling user login e.g: Regular Users , Staff Users etc etc
If something is missing from one of the grouped attributes it could cause this. I had this problem before, an attribute that was in the grouping was inadvertently removed from a user object causing intermittent login problems which appeared to be password related

So I'm thinking - is the password really going pop or is one or more of the main browsers doing something differently with their password storage/auto fill?. I use chrome on my main PC and for testing purposes, log in on iPad 4 (Safari) and iPhone 7 (Safari) and it's never happened to me

Maybe try disable the saving of passwords on the user side, see if it goes away - there is a trick on how to do this mentioned somewhere in this forum

BLOMASKY

1st, is the app they are logging onto the DEFAULT app (created when you installed Aware?)

IF not,
2nd, do you have a URL that looks like: http://yourIP:8080/AwareIM/logonOp.aw?domain=MyApp
and expect them to type their user name and password?

If so, If they make a mistake, it will present a login window that is attached to the DEFAULT app instead of MyApp.

If all this is true, then there is an easy fix.

Bruce

rocketman

BLOMASKY wrote
1st, is the app they are logging onto the DEFAULT app (created when you installed Aware?)

IF not,
2nd, do you have a URL that looks like: http://yourIP:8080/AwareIM/logonOp.aw?domain=MyApp
and expect them to type their user name and password?

If so, If they make a mistake, it will present a login window that is attached to the DEFAULT app instead of MyApp.

If all this is true, then there is an easy fix.

Bruce

Hi Bruce - No its not the default app and no - they should all be using logonAdmin.html. I may have shown a few how to construct their own url in the past but they should all have the domain, username and password embedded in the URL. and I've discontinued that practice anyway, since about 2 years ago. I'm now trawling their own club websites to see if anyone has put a logonOp.aw link in place that might be causing the issue

Have later versions fixed this (for me) problem. If we use logonOp.aw?domein= then it would make more sense for AIM to somehow stick with the correct business space if a user gets it wrong. I would have thought it would be easy enough to pick the business space name (domain=) out of the url string. I was thinking its time I upgraded but have been working on the age old principle "if it ain't bust - don't fix it"

rocketman

ACDC wrote
Do you have any grouped object set with users i.e. more than one object handling user login e.g: Regular Users , Staff Users etc etc
If something is missing from one of the grouped attributes it could cause this. I had this problem before, an attribute that was in the grouping was inadvertently removed from a user object causing intermittent login problems which appeared to be password related

The SystemUsers group has RegularUsers and Members and there are differences - but they have been there from day one some 10 years ago. The attributes I use to do group searches haven't changed - but I'll keep looking. Just going to load an old BSV up and check for differences. I can't recall deleting anything but as you say, I may have inadvertently done something stupid.

ACDC

Also, next time a user has a login problem ask them to make a login attempt while you are monitoring the the system log , you may pick up some clues

If it shows a normal password error, then chances are the problem is on the client side (like inputting a password with a space character) Maybe ask them for their password and try login from your side and see if it persists

kklosson

I know for a fact there are some characters that the server can't deal with, like #. I've created my own password formula. In my experience, it's nearly impossible to check a password due to encryption. Others correct me if I'm wrong.

rocketman

Sorry this is a late reply to all.

I found some corruption in one of the databases (main members table) which I was able to successfully remove manually with MySQL workbench tools. I also removed the password field from the main members record and made the password change process an explicit button click and new form with just the password field on it.

Seems to have done the business. All is now back to normal .... quiet, which is just the way I like it

Jaymer

rocketman wrote
I also removed the password field from the main members record and made the password change process an explicit button click and new form with just the password field on it.

yes, i've found i prefer this.
i hate the annoying 'password verification' popup, and if you're editing a user's record (as an admin) you won't know their PW if it decides to make you verify it.