| Anonymous | Login | Signup for a new account | 2010-09-09 16:44 UTC |  |
| Main | My View | View Issues | Change Log | Roadmap |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update | |
| 0000115 | Mana Client | Interface | public | 2010-03-31 11:55 | 2010-05-29 20:31 | |
| Reporter | thorbjorn | |||||
| Assigned To | Jaxad0127 | |||||
| Priority | high | Severity | major | Reproducibility | N/A | |
| Status | resolved | Resolution | fixed | |||
| Platform | OS | OS Version | ||||
| Product Version | 1.0.0 | |||||
| Target Version | 1.0.0 | Fixed in Version | 1.0.0 | |||
| Summary | 0000115: Client suggests registration is always possible | |||||
| Description | The Register button is enabled unconditionally, even though at least on eAthena it can be turned off, and for example server.themanaworld.org has it turned off. This is very confusing for new players. The client should be told whether a server supports registration, if necessary through the server list file. It should then be made clear to the user that he can't register through the client, and maybe even how to register instead. | |||||
| Tags | No tags attached. | |||||
| Attached Files | ||||||
 Relationships |
|
 Relationships |
|
Notes |
|
|
(0000343) Jaxad0127 (administrator) 2010-03-31 15:01 |
The server list is a possible place for it. We could use the server information packet the client requests before showing that dialog to send information. |
|
(0000386) Bertram (developer) 2010-04-22 12:06 edited on: 2010-04-22 12:07 |
"We could use the server information packet the client requests before showing that dialog to send information. " -> Please, no. Consider minimizing by all means the server network load, following at least the 2 rules below: 1. Every data that can be computed by the client, has to be computed by the client only. (E.g.: Imagine the Max HP formula depends on level and vitality, if the client has already received the level and the vitality from the server, then it should be able to compute the Max HP before displaying it. The server shouldn't have to take care about it.) 2. Every configuration data that can be passed by other means than network stack should be passed in some other file, rather than again and again by the server netcode. (Registration enabled, Password min/max length, number of max characters per account, minimum client version, ...) are some examples. Thanks for considering this point of view. |
|
(0000387) Jaxad0127 (administrator) 2010-04-22 12:20 |
This should already be fixed. Manaserv returns an error when the client requests registration parameters (requested when the button is pressed) and I've already changed tmwAthena to send this state in the server information packet, which is always requested (I added a 32-bit flags field; this is the only flag so far). |
|
(0000388) Bertram (developer) 2010-04-22 14:22 edited on: 2010-04-22 15:13 |
Ok, then. What's left to be done? Better error reporting from the client? The current protocol packets should be changed, maybe: PAMSG_REQUEST_REGISTER_INFO = 0x0005, // APMSG_REGISTER_INFO_RESPONSE = 0x0006, // B byte registrationAllowed, byte minNameLength, byte maxNameLength, string captchaURL, string captchaInstructions To something like: PAMSG_REQUEST_REGISTER_CAPTCHA = 0x0005, // APMSG_REGISTER_CAPTCHA_RESPONSE = 0x0006, //B byte CaptchaRequestAccepted, [string captchaURL, string captchaInstructions] min and max length and enabled in client should be obtained via the serverlist.xml maybe, if that's not already the case. ;) |
|
(0000444) Jaxad0127 (administrator) 2010-05-07 04:17 |
Let's keep it how it is. serverlist.xml doesn't need everything, and it shouldn't have everything. |
|
(0000450) Bertram (developer) 2010-05-07 07:06 |
"Let's keep it how it is. serverlist.xml doesn't need everything, and it shouldn't have everything. " --> True, but how to handle server branding values (mix max for login, pass, ...) obtained after the server selection choice? Everything given by the server net protocol? --> A definite no. And we still need a point saying how and/or where the user can register. Maybe we'll need a third xml file, specific to the chosen server, giving its capabilities, and downloaded after server selection? To fill this gap, I propose something like serveroptions.xml, with parameters like: minLogin, maxLogin, minPass, maxPass, acceptableDigits, registrationMode {client, web}, registrationURL (if web), maxCharactersPerAccount, mainLanguage guildEnabled, partyEnabled, auctionEnabled, pvpEnabled. That should be a good start. What do you think? |
|
(0000452) Jaxad0127 (administrator) 2010-05-07 07:11 |
There are no limits on passwords for Manaserv, as they are hashed anyways before being sent to the server. |
|
(0000453) Bertram (developer) 2010-05-07 07:17 |
They will be set to 0 in that case :) And about the concept? |
|
(0000454) Jaxad0127 (administrator) 2010-05-07 13:56 |
Why do we need a field we won't ever use? For eAthena and tmwAthena, the fields (username and password) are fixed anyways. Any server that changes them will need a new protocol. Username details for Manaserv should be sent with CAPTCHA information, IMO. Max characters per account is fixed in the client for now. Language is an iffy thing anyways. Guild, party, and auction enabled statuses should be sent from the server in a binary package, IMO, if we even need to send them. PvP will likely vary on a per-map basis. |
|
(0000456) Bertram (developer) 2010-05-10 07:32 edited on: 2010-05-10 12:08 |
"Username details for Manaserv should be sent with CAPTCHA information, IMO." -> Hmm, understand that I agree about this being a viable way to implement it, but I simply fear the network load for login attempts. DoS attacks are usually based on the load linked to credentials, that's why I'm being pedantic on this one ;) "Max characters per account is fixed in the client for now." -> And I'm sure we'll fix it by the time we agree how set up that part for manaserv. "Language is an iffy thing anyways. Guild, party, and auction enabled statuses should be sent from the server in a binary package, IMO, if we even need to send them." -> These parameters could change the way the main buttons are displayed in the client, or we can handle this in updates files, maybe. "PvP will likely vary on a per-map basis." -> Ah, ok, didn't know that. I propose to find a way to move these somewhere else (in serverlist.xml or in another specific xml file): byte minNameLength, byte maxNameLength, and add, at least: minPass, maxPass, acceptableDigits, registrationMode {client, web}, registrationURL (if web), maxCharactersPerAccount. What do you think? |
|
(0000459) Jaxad0127 (administrator) 2010-05-10 14:22 |
Once again, sending password details is pointless, as the client only sends a hash. What is acceptableDigits for? |
|
(0000460) Bertram (developer) 2010-05-11 09:51 edited on: 2010-05-12 06:56 |
"Once again, sending password details is pointless, as the client only sends a hash" -> Ok, one point. But minName, maxName remain. "What is acceptableDigits for?" -> or 'acceptableCharacters'. This could be used to disallow some special characters in login names, to cope with the # problem we had in tmwAthena lately, for instance. This option could also be moved to the manaserv.xml file. And an error return message added to the protocol when the player is using unallowed characters. |
|
(0000461) Bertram (developer) 2010-05-12 07:05 |
Ok, so far we still have to handle (at the login/register level): minLogin, maxLogin, maxCharactersPerAccount, registrationMode {client, web}, registrationURL (if web). -> Why not letting them in the serverlist.xml for now, or do you have a better idea? If guild, party and pvp is enabled can be handled in the update data. We still need to know where to store guildsEnabled and partiesEnabled values but it can be handled using the net protocol as we can send them once after the login sequence. I'll drop the mainLanguage parameter until we have set up a server handling localization. |
|
(0000503) Jaxad0127 (administrator) 2010-05-28 20:02 |
Is there anything else to be done for this for Mana 1.0? |
|
(0000508) Bertram (developer) 2010-05-29 19:49 |
No, the 1.0 branch handles registration nicely by disabling the register button when necessary. And it's working for ManaServ. Issue resolved by your commit. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2010-03-31 11:55 | thorbjorn | New Issue | |
| 2010-03-31 15:01 | Jaxad0127 | Note Added: 0000343 | |
| 2010-04-22 12:06 | Bertram | Note Added: 0000386 | |
| 2010-04-22 12:07 | Bertram | Note Edited: 0000386 | View Revisions |
| 2010-04-22 12:20 | Jaxad0127 | Note Added: 0000387 | |
| 2010-04-22 14:22 | Bertram | Note Added: 0000388 | |
| 2010-04-22 15:12 | Bertram | Note Edited: 0000388 | View Revisions |
| 2010-04-22 15:13 | Bertram | Note Edited: 0000388 | View Revisions |
| 2010-05-07 04:17 | Jaxad0127 | Note Added: 0000444 | |
| 2010-05-07 07:06 | Bertram | Note Added: 0000450 | |
| 2010-05-07 07:11 | Jaxad0127 | Note Added: 0000452 | |
| 2010-05-07 07:17 | Bertram | Note Added: 0000453 | |
| 2010-05-07 13:56 | Jaxad0127 | Note Added: 0000454 | |
| 2010-05-10 07:32 | Bertram | Note Added: 0000456 | |
| 2010-05-10 12:08 | Bertram | Note Edited: 0000456 | View Revisions |
| 2010-05-10 14:22 | Jaxad0127 | Note Added: 0000459 | |
| 2010-05-11 09:51 | Bertram | Note Added: 0000460 | |
| 2010-05-11 09:51 | Bertram | Note Edited: 0000460 | View Revisions |
| 2010-05-12 06:56 | Bertram | Note Edited: 0000460 | View Revisions |
| 2010-05-12 07:05 | Bertram | Note Added: 0000461 | |
| 2010-05-28 20:02 | Jaxad0127 | Note Added: 0000503 | |
| 2010-05-29 19:49 | Bertram | Note Added: 0000508 | |
| 2010-05-29 20:31 | Bertram | Assigned To | => Jaxad0127 |
| 2010-05-29 20:31 | Bertram | Status | new => resolved |
| 2010-05-29 20:31 | Bertram | Resolution | open => fixed |
| 2010-05-29 20:31 | Bertram | Product Version | => 1.0.0 |
| 2010-05-29 20:31 | Bertram | Fixed in Version | => 1.0.0 |
|
Issue History |
| Copyright © 2000 - 2010 MantisBT Group |
 |