marco giudici Messages: 174 Registered: February 2013 Location: Italy
I have a little problem with DataSourceSecurityFilter.
I configured this type of filter (see below the deatils), but when start my application and insert a correct username and password on Login form, the system doesn't continue and re-submit the Login form.
In Config.ini, I insert this rows:
### Servlet Filter Runtime Configuration
org.eclipse.scout.http.servletfilter.security.DataSourceSecurityFilter#selectUserPass=SELECT USERACCOUNT FROM MYUSERTABLE WHERE LOWER(USERACCOUNT)=? AND PASSWORD=?
Ensure your passwords are stored encrypted in the database (See: 'org.eclipse.scout.http.servletfilter.security.DataSourceSecurityFilter.negotiate(HttpServletRequest, HttpServletResponse, PrincipalHolder)' and the encryptPass method in the same class). If you want to store plain passwords create your own extension of DataSourceSecurityFileter and register this subclass as filter. Override the encryptPass method with empty or what ever else content.
To get encrypted passwords the 'org.eclipse.scout.commons.Base64Utility.decode(String)' may be used from a simple main class.
Ok that was a try. Now could you provide some more information. Do you get any exception or error? Are you able to reach a breakpoint in 'org.eclipse.scout.http.servletfilter.security.DataSourceSecurityFilter.negotiate(HttpServletRequest, HttpServletResponse, PrincipalHolder) . return STATUS_CONTINUE_WITH_PRINCIPAL;'?
I might be able to help you here, as I was also having some problems with DataSourceSecurityFilter. I managed to solve them by setting breakpoints in the DataSourceSecurityFilter class and looking at what being passed from the login dialog to the server and back.
You can find the DataSourceSecurityFilter.negotiate() method using the Navigate -> Open Type (or just Ctrl + Shift + T) window and typing DataSourceSecurityFilter into it.
I recommend setting breakpoints in navigate(), isValidUser() and encryptPass().
I noticed that Base64Utility.encode(EncryptionUtility.signMD5()) generates a different password digest when called within Scout, compared with running from the main method of a stand-alone java app. Not sure why, but as long as it is called from within Scout it remains consistent.