currently, the client needs to do verification and this includes the use of the passw.txt file. i was wondering if we can add new logins to the txt file to include more users. technically, i think this is possible. but does sgs provides a way to add new user login?
if not, i think i will have to work around to do a registration form and update the passw.txt file.
any suggestions?
Not sure if I understood your question.
The client does not do the validation, the server does.
On user connection, the Validator specified in the deploymenty xml is instanced and invoked by the server. It returns a list of what information it needs to do validation. The server then communciates this to the client… The client collects this information and returns it to the server.
The FlatFileUserValidator, which is a simple example that ships with the SDK, uses the passwd.txt file.as its validation data. This is a sever side file. You cna edit it to add users. I am pretty sure that there are comments in the file itself that explain its format.
As alluded to above, when we get the stack extension SDK out you will be able to write your own Validators that do authentication how ever you want.
thanks. stated in the deploy.xml
<VALIDATOR moduleclass="com.sun.gi.comm.users.validation.impl.FlatFileUserValidator">
<PARAMETER tag="password_file_url" value="file:passwd.txt" />
</VALIDATOR>
but i couldnt locate the ‘com.sun.gi.comm.users.validation.impl.FlatFileUserValidator’ in the server api. ???
and in the passwd.txt there really aint any comments to tell indicate the purpose of field. but i roughly got the idea that the 1st field is the id and the 2nd field is the password.
i’m looking forward to the release of the stack extension SDK =)
oh i see. thanks for the info. one more question: is it possible to do user registration with SGS?
if the user wanted to participate in a game, he/she needs to register first. but with the current SGS implementation, the login id and password are in the passwd.txt, which the application may not had access to. so what i have in mind is to use JSP, servlet and beans to read the passwd.txt file for existing password and to inform the user that that particular id has been taken else, it will update the passwd.txt of the new id and password. then the user can run the jar to login the game and play.
actually, i want to know how to do user registration with SGS.
It appears from some of the messages and documentation available that the version of SGS available for download now is really geared at initial development, PoC and beta environments. ( Jeff, please correct me if I’m wrong ??? ). In those cases direct communication between the potential player and the developer would be common (maybe even required) and the developer could manually update the authentication.
The expanded SDK Jeff referenced will allow use of more dynamic authentication methods than basic flatfile and you will probably find easier methods available to you to authenticate against and add new users to a server-side database ( example ) rather than dealing with updating a flatfile. Until that is available, I would imagine if you don’t want to use the manual-entry method, you could create an extra layer at the front end like you suggested. If the user does not already exist in the flatfile then instead of getting an authentication error they could be redirected to a page that will allow them to register a new name and password into the file. But going thru too much work in that area when it’s going to change soon ( and you may not really need it yet anyway ) may not be worth it.
Just a thought.
The answer is that the FlatFileUserAuthenticator, as others have pointed out, is a minimal example intended as a guide and tool for developers.
The version of the SGS contaiend in the SDK is for development purposes only. You cannot, by the license, run a service for users outside of your development group with it.
A real service would likely write their own authenticator using the stack extension SDK. (Which is coming, but we’ve held up on releasing because we are doing an architectural review in light of the “big back end” which is the real, scalable server system that someone running a service would use. Its possible that as a result of this review some interfaces may chnage some and we didnt want you to run off and start writing code that would be incompatable with the actual production environment.)
This custom authenticator would talk to their own database, or however else they themselves manage users.
thanks so much for the info. =) ;D