Implementing a custom login on the server-side is a simple process. SFS2X fires the following two login events.<\/p>\n
<\/p>\n
In order to add our\u00a0custom login logic we\u00a0should follow these two\u00a0steps:<\/p>\n
Launch the AdminTool<\/strong>, open the Zone Configurator<\/a> module and enable your Zone’s Use custom Login\u00a0<\/em>setting; then restart SFS2X.<\/p>\n Create a new server-side Extension that extends the SFSExtension<\/em> class. The\u00a0init<\/strong>() method should look like this:<\/p>\n Now create the LoginEventHandler<\/em> class which will take care of the user name\/password checking. In the following example two specific user names are not allowed to login.<\/p>\n If one of the two unwanted names is detected, an SFSException<\/strong> can be fired. In doing so we provide a message that is logged on the server-side and an SFSErrorData<\/strong> object which contains the error code (SFSErrorCode.LOGIN_BAD_USERNAME<\/em>) and the bad name itself.<\/p>\n Typical error codes used in this context are SFSErrorCode.LOGIN_BAD_USERNAME<\/em> andSFSErrorCode.LOGIN_BAD_PASSWORD<\/em>, both taking an additional parameter which is the wrong name or password.<\/p>\n Now this is a very simple example that just shows how to deny access to users with a name of Kermit<\/strong> orGonzo<\/strong>. Of course your logic might require a little more sophistication but you should get the idea. When you need to stop the execution of the login process you just throw an SFSLoginException<\/strong>.<\/p>\n If no exception is thrown the system will accept the user and continue the login process. Once all these checks are passed the user is finally logged in the Zone. At this point the server code will receive an USER_JOIN_ZONE<\/strong> event, if you subscribed to it.<\/p>\n This last step is optional and it won’t be necessary in many cases. TIP:\u00a0<\/strong>When working with asynchronous events such as USER_LOGIN<\/strong> and USER_JOIN_ZONE<\/strong> it’s a bit more difficult to maintain the state of the current transaction\/operation.<\/p>\n A convenient way to maintain the state is to use the user Session object. In particular the Session object<\/a> allows to store custom parameters as key-value pairs (see the JavaDoc, methods getProperty\/setProperty, etc).<\/p>\n<\/div>\n The user password is never transmitted in clear from the client to the server, for security reasons. In order to be able to compare the encrypted password with your database original password we provide a convenient method in the API.<\/p>\n The method call will return true if the password match and false otherwise.<\/p>\n On the client side there’s absolutely no difference between a “standard” login and a “custom” one. All we\u00a0need to do is adding a listener for the SFSEvent.LOGIN<\/strong> event to receive the server response, and send a LoginRequest<\/strong> to log into a Zone.<\/p>\n We\u00a0can check the AS3 documentation<\/a> and the examples for all the details on how to do this. For the other languages the process is the same. Another interesting reading, related to this topic, is the discussion about the User Permissions<\/a>.<\/p>\n There are cases in which we\u00a0need to change the name provided by the user at login time with another one extracted from the database. An example is when the user logs in with an email address as the login name, but on the database we\u00a0have stored a\u00a0nickname, which should be used instead.<\/p>\n There is a simple convention that allows us\u00a0to provide an alternative name to the login system. In the USER_LOGIN<\/strong> event we\u00a0are passed an empty SFSObject<\/strong> that can be used to return custom data to the client. We\u00a0just need to provide the name in that object under a very specific (and reserved) key name. See the code below:<\/p>\n If your application requires different levels of access for different user profiles you can also configure a User’s permission id during the login phase. There are a number of preset user levels such as “Guest”, “Registered”, “Moderator”, “Admin” and custom ones can be added if necessary.<\/p>\n2) Server code<\/h3>\n
\r\n@Override\r\npublic void init()\r\n{\r\n trace("My CustomLogin extension starts!"); \r\n\r\n \/\/ Register for login event\r\n addEventHandler(SFSEventType.USER_LOGIN, LoginEventHandler.class);\r\n}\r\n<\/pre>\n\r\npublic class LoginEventHandler extends BaseServerEventHandler\r\n{\r\n @Override\r\n public void handleServerEvent(ISFSEvent event) throws SFSException\r\n {\r\n String name = (String) event.getParameter(SFSEventParam.LOGIN_NAME); \r\n\r\n if (name.equals("Gonzo") || name.equals("Kermit"))\r\n {\r\n\r\n \/\/ Create the error code to send to the client\r\n SFSErrorData errData = new SFSErrorData(SFSErrorCode.LOGIN_BAD_USERNAME);\r\n errData.addParameter(name);\r\n\r\n \/\/ Fire a Login exception\r\n throw new SFSLoginException("Gonzo and Kermit are not allowed in this Zone!", errData);\r\n }\r\n }\r\n}\r\n<\/pre>\n
\nThere are other things that could go wrong during this phase, for instance:<\/p>\n\n
\nTypically you will use this when you need to perform specific actions after the user is logged in the system (like setting User Variables, auto-join a Room, etc).<\/p>\n3) Secure passwords<\/h3>\n
\r\ngetApi().checkSecurePassword(session, clearPass, encryptedPass);\r\n<\/pre>\n
4) Change the user name at login time<\/h3>\n
\r\npublic class LoginEventHandler extends BaseServerEventHandler\r\n{\r\n @Override\r\n public void handleServerEvent(ISFSEvent event) throws SFSException\r\n {\r\n String name = (String) event.getParameter(SFSEventParam.LOGIN_NAME);\r\n ISFSObject outData = (ISFSObject) event.getParameter(SFSEventParam.LOGIN_OUT_DATA);\r\n\r\n \/\/ ...\r\n \/\/ your login logic goes here\r\n \/\/ ...\r\n\r\n \/\/ Provide a new name for the user:\r\n String newName = "User-" + name;\r\n outData.putUtfString(SFSConstants.NEW_LOGIN_NAME, newName);\r\n }\r\n}\r\n<\/pre>\n5) Set User’s permissions<\/h3>\n