Hey Dominic, thanks for your response. I really appreciate it. "When the user returns your system expects the user to know the unknown password.”
I guess I didn’t explain it well, sorry. In the login as guest, the user never needs to enter the password or know it. There is no textfields for them to enter it anyway in that scenario on the Mobile App, just a button. So… "If the DeviceID is globally unique perhaps you don't need a password, the Device itself can act as a password.” Exactly, in login as guest the deviceID is unique will act as the password. I generate a password because the password field is Not nullable in the Database. ;) Also, the deviceID acting as the password in this scenario is the catch-22. Since that will be the only piece of data coming into the request and we are using PasswordMatcher, because we also have to support a “real” user that registers and when real users login, they do enter their one created username/password. (This sentence only makes sense in my head, sorry) It is the combination of real users and login as guest use cases with only being able to use one Matcher with one PasswordService with one HashService for our Realm. Hmmm as I say that, maybe that is my solution, make two different Realms, one for real users and one for login as guest, then for real users use the PasswordMatcher and for login as guest use SimpleCredentialsMatcher. See you helped me out tremendously, Thanks Mark On Feb 14, 2014, at 1:40 AM, Dominic Farr <[email protected]> wrote: > This line. > ... generate a password for them, which we never send to them. > > This is the start of your design problem. > > You generate a password which the user never knows. > > When the user returns your system expects the user to know the unknown > password. > > No amount of software will solve this problem. > > What is the password protecting? If the DeviceID is globally unique perhaps > you don't need a password, the Device itself can act as a password. > > > On 14 February 2014 02:12, [email protected] <[email protected]> wrote: > So in our application (REST) we have the standard users with logging in via > username/password. However, we also have a login as guest. However, guest > users are still full users in our system. When a user signs in as guest for > the first time a request is sent with just a FingerPrint, this is a HASH sent > from the client to the REST api. To determine that this is the first time > this fingerprint/deviceID has been sent I do a db lookup WHERE db.fingerPrint > = loginRequest.fingerPrint. > > If it doesn’t return a record then that means it is a new guest and we create > a User instance and store it in the db. We generate a username GuestNNN and > generate a password for them, which we never send to them. If it does return, > then we take the userName from the db and the passed in signature and create > a SignatureAuthenticationToken, which just extends > UsernamePasswordAuthenticationToken and the constructor we pass in username > and fingerprint String. This works when we encrypt the fingerPrint with > PasswordService and store it encrypted. > > However, this does not work then on subsequent logins by that guest, because > in order to get the userName I have to query the db using the same WHERE > clause > WHERE db.fingerPrint = loginRequest.fingerPrint > > It fails because the incoming login request has the fingerPrint unencrypted > and the where clause will never match what is in the db, because the db has > it stored encrypted. > > If I try to just store the fingerprint in the db unencrypted, then the login > will fail because we are using PasswordMatcher with DefaultHashService which > will always take the fingerprint and encrypt it and compare it to what is in > the db, which is now unencrypted. So I am sort of damned if I do, damned if I > don’t. > > The login as guest request will always just have the fingerPrint, the client > will never know or send us the userName because it doesn’t know it. > > We can’t use rememberMe as unauthenticated user as guest because we need to > make them an actual user with data stored in the database that on subsequent > logins keeps their information etc. > > Any ideas? > > Thanks > > Mark > >
