Andreas,
The code sample I sent you wasn't quite complete. I am working on a new version that will allow you to login (connected or disconnected). Once the user logs in, he/she will be able to connect or disconnect through a Connect/Disconnect button.
Your comment that:
According to the manual if in ibconfig there is true option for LoginManagerRequired, the developer HAS to implement IPersistenceLoginManager to use the Login function. Reading reversely someone gets the meaning: If you do not login you cannot get the data plain and simple.
This isn't quite true. If you do not login, you can't get data from the database. However, you can still get data from offline storage,
Your error message about "failing to login before using the Persistence Manager" will be fixed in my new version. In this version, I will not have a "real" LoginManager and a "fake" client LoginManager. I will have a single LoginManager that knows how to read SecureUser data from the database (if able to connect to the database) or how to validate the username and password from the file system (if not able to connect to the database)
Another change in my next version is that the SecureUser will be returned to the Server assembly.
I thought a lot about how to validate the username and password and came up with a better approach than reading the list of SecureUsers from offline storage. After logging in successfuly (using the SecureUser table on the Server), I will encrypt some string using the username and password as an encryption key). When a user tries to login later, the username and password will be used to see if it can unencrypt the encrypted string. It the unencryption is successful, the login will be declared successful. The IPrincipal will be returned from the Login function, and the IdeaBlade framework will set the IsLoggedIn property of the client-side Persistence Manager to true.
One final improvement would be to require a login using info from the database when connecting to the database if the current login used local data from offline storage. Just because a username and password once worked doesn't mean that that same username and password will always work. That means that there is a slight security hole here. If my username and password become invalidated, I can still access old data that I stored in local storage, but I can't read in any new data from the database.
With this approach, do you still draw the same Bottom Line?
Bottom Line: I wish DevForce had the option to handle disconnected login without failing security considerations. In a BOS deployment scenario this would be unacceptable, so why IdeaBlade says: Use BOS for fully smart client deployment? Of course maybe i miss something.
When I complete this new revised version, I will send it to you.
|