Validate User E1 credentials in BSFN

BOster

BOster

Legendary Poster
I need to validate passed user E1 credentials in a BSFN. I have found several different API calls that look like they would work - which one should I use? Or is there a different one?

No examples of these in pristine BSFN code that I could find but they look like what I need:
jdeSecValidateUserByPwd
jdeSecValidateXMLUserByPwd

This was found in a BSFN but .h notes that it is deprecated and jdeSecValidateXMLUserByPwd s/b used instead:
ValidateXMLUser

I believe these would work as well (and I found some code examples) but I imagine they go beyond simple username/password validation and would have the additional overhead of actually initializing a user environment.
JDB_InitEnvOvr
JDB_InitEnvOvrExtended
GetWfEnvironmentByPassword
 
Hi Brian,

If your intention is just to validate credentials, all you need to do is call JDB_InitEnvOvrExtended followed by JDB_FreeEnv to free the environment handle. If you need to do more (like initializing a user etc.), you should call JDB_InitUser and take it from there. Hope this helps.
 
Last edited:
It does help, thanks. Have you ever seen jdeSecValidateUserByPwd or jdeSecValidateXMLUserByPwd used? I was hoping they would be even more light weight then JDB_InitEnvOvrExtended.
 
I have not seen jdeSecValidateUserByPwd or jdeSecValidateXMLUserByPwd being used. May be someone else here has some info on it? It would be nice to know.
 
Brian,

The business function I user to validate password is B91300C.ValidateUserPassword which is used in the JDE scheduler.
 
Brian,

The business function I user to validate password is B91300C.ValidateUserPassword which is used in the JDE scheduler.

Good to know. That BSFN calls ValidateXMLUser and the header file says its deprecated and to use jdeSecValidateXMLUserByPwd so I guess I would feel confident in using jdeSecValidateXMLUserByPwd.
 
So jdeSecValidateXMLUserByPwd appears to work just fine (and is very fast) except that it doesn't disable the user's account after x number of failed attempts. JDB_InitEnvOvrExtended, all though slower, will disable the user's account after x number of failed attempts. However, on a local web dev fat client it will open win32 dialogs and in the case of a disabled account will stop execution until the dialog is closed. Does JDB_InitEnvOvrExtended behave differently when ran on a server?
 
Are you using LDAP authentication? If so, it does not make sense for jdeSecValidateXMLUserByPwd not to disable the user account. JDB_InitEnvOvrExtended will not open any win32 dialogs when run on the server.
 
No LDAP. Just JDE authentication, and JDE auth is not linked to active directory/LDAP. Thanks for the info on JDB_InitEnvOvrExtended, I may have to use that since it disables user accounts after n failed attempts and jdeSecValidateXMLUserByPwd appears not to.
 
So jdeSecValidateXMLUserByPwd appears to work just fine (and is very fast) except that it doesn't disable the user's account after x number of failed attempts. JDB_InitEnvOvrExtended, all though slower, will disable the user's account after x number of failed attempts. However, on a local web dev fat client it will open win32 dialogs and in the case of a disabled account will stop execution until the dialog is closed. Does JDB_InitEnvOvrExtended behave differently when ran on a server?

Hi Brian,

can you share how you used jdeSecValidateXMLUserByPwd?

Thanks,
Jefrey
 
Its pretty straight forward.

Code:
	JCHAR szAuthToken[(MAX_AUTH_TOKEN_LENGTH * 2) + 1]={0};		
	BOOL bIsValidated=FALSE;
	
	bIsValidated =
		jdeSecValidateXMLUserByPwd(pszUserName, pszPassword, szAuthToken);
 
Be careful when using JDB_InitEnvOvr as this will open a new user session for the user. It can cause issues. But yes I needed the password and USER ID

I had to use this when trying to get an E1 subsystem job to send workcenter messages to a different user.
It can mess up and keep the overriden work center open for future jobs.
 
Back
Top