ultima03 wrote...
Non sql data storage is not reliable. (more like horrible)
Perhaps you've failed to note that both SQL and Non-SQL options are available in the above posts.
Securing Your Server Without Master Server Authentication
Débuté par
FunkySwerve
, juil. 10 2011 11:50
#26
Posté 05 janvier 2012 - 05:01
kalbaern
-
- Members
- 824 messages
Perhaps you've failed to note that both SQL and Non-SQL options are available in the above posts.
Retour en haut
#27
Posté 05 janvier 2012 - 05:19
ultima03
-
- Members
- 38 messages
kalbaern wrote...
ultima03 wrote...
Non sql data storage is not reliable. (more like horrible)
Perhaps you've failed to note that both SQL and Non-SQL options are available in the above posts.
In wich realm did I state that there is no other option than non-sql?
anyway all funkyswerve work is always so messy and unreadable, unprofessional. Now he offers a natural bioware Database system wich is just idiotic knowing that database's ugly flaws will make his system useless with a ratio of 100%. why no notice ? And, anyway, this is just a workaround that pretend that the first to log in is the legitimate owner, wich is stupid.
Modifié par ultima03, 05 janvier 2012 - 06:12 .
#28
Posté 06 janvier 2012 - 01:30
kalbaern
-
- Members
- 824 messages
ultima03 wrote...
kalbaern wrote...
ultima03 wrote...
Non sql data storage is not reliable. (more like horrible)
Perhaps you've failed to note that both SQL and Non-SQL options are available in the above posts.
In wich realm did I state that there is no other option than non-sql?
anyway all funkyswerve work is always so messy and unreadable, unprofessional. Now he offers a natural bioware Database system wich is just idiotic knowing that database's ugly flaws will make his system useless with a ratio of 100%. why no notice ? And, anyway, this is just a workaround that pretend that the first to log in is the legitimate owner, wich is stupid.
Claiming Funky's work is "always so messy and unreadable, unprofessional", can mean only one of two things. You're deliberately trolling against him or lack the knowledge to discern his scrips and henceforth resort to name calling to disguise you're own ignorance.
As for the Bioware DB soultion offered, that was an alternative only. There's many other alternatives available to PW Admins as well. If a PW has no other DBs in use and the Admin/Host lacks confidence in "learning something new", the Bioware DB will work just fine. Most of "Us" know one another and share such information freely. Admins of PWs also have access to private help through a forum set up elsewhere.
You're assertion that the Bioware option is useless and will fail further highlights your lack of knowledge. For most PWs, if the only thing they need a DB for is Player Vault protection, there's nothing wrong with using the Bioware DB. I personally know of 7 smaller PWs that have used it thusly for over a year now with no issues. So much for your own paranoid claims. I also know of 2 PWs that have used it for other uses related to character tracking, one for 8 years and the other 6 years now, with no issues ever arising. Granted, the Bioware DB is ineficient, but used sparringly, it works well. Since many PWs use NWNX2, SQL or a variant is most likely more commonly used. Especially if there are custom races/subraces, custom classes, custom spells, custom feats or skills, persistance, etc... in use.
Apparently you fail to also understand just what the "MS" did. It only prevented another player from joining an online game with a Login already in use elsewhere. It was not foolproof. It was easilly bypassed as well. Thus, it offered a false sense of security and actually enabled "griefers" to cause all sorts of mischief. Most large PWs recognized its limitations and took other measures long ago. Those few that didn't, did so shortly after the "MS" went down for good. The majority of PWs online today are far, far, far more secure than most were a few years ago.
With the MS down, its true, someone could use "your" login to play. They'd not be able to access most servers you play on however. Lacking your CD Keys, a server using any of the means posted here along with the many variants most of us use, the player trying to "emulate" your account would be booted, banned, PCs held immobile somewhere or whatever a Admin/Host desired as punishment or an outcome.
Your fears are unfounded and unmeritted.
As for awaiting a response from Bioware, they gave one long ago. They were making available what was needed for Atari to take over the responsibility. Its Atari's duty and not Bioware's to continue support for this game. Please go rail against them for their lack of dedication to the player base.
#29
Posté 06 janvier 2012 - 04:51
ultima03
-
- Members
- 38 messages
You're so wrong it's unbelievable. I could just quote myself again, after your post responding to it, because it remain true and you don't seem to know what you're talking about.
#30
Posté 06 janvier 2012 - 05:39
ultima03
-
- Members
- 38 messages
Why natural bioware database is not reliable, and why no dev should offer a solution using it :
- Limited to 32 chars, brutally truncated if longer
- Var name must be unique throughout the entire database no matter if it is an int or a float, or a string... (if not, it will be simply crushed)
- Getter and Setter for CampaignLocation are absolutly not reliable, the database can get invalid if u change the area layout in the toolset (!)
- Database grow big and fast because the data that you asked for deletion will not be deleted but simply flagged as deleted. uglier : If you try to modify an entry, instead of overriting it, it will make a new one and flag this one as deleted.
- One last : it's a slow database solution.
Why would funkyswerve or anyone serious provide a solution using this, especially concerning a Security problem ? he should just delete it and leave the one with mysql. Its just like the people from Avlis providing a craft system with
bioware db, and next to it a mysql version, the first one can be thrown
directly to the bin.
And nor players nor developper should have to worry about this problem at all.
- Limited to 32 chars, brutally truncated if longer
- Var name must be unique throughout the entire database no matter if it is an int or a float, or a string... (if not, it will be simply crushed)
- Getter and Setter for CampaignLocation are absolutly not reliable, the database can get invalid if u change the area layout in the toolset (!)
- Database grow big and fast because the data that you asked for deletion will not be deleted but simply flagged as deleted. uglier : If you try to modify an entry, instead of overriting it, it will make a new one and flag this one as deleted.
- One last : it's a slow database solution.
Why would funkyswerve or anyone serious provide a solution using this, especially concerning a Security problem ? he should just delete it and leave the one with mysql. Its just like the people from Avlis providing a craft system with
bioware db, and next to it a mysql version, the first one can be thrown
directly to the bin.
And nor players nor developper should have to worry about this problem at all.
Modifié par ultima03, 06 janvier 2012 - 11:25 .
#31
Posté 06 janvier 2012 - 05:45
zunath
-
- Members
- 83 messages
Alright, I'll bite.
Funkyswerve has offered the community more than anything you ever have or will. If you've got a better solution then post it for everyone to use. Otherwise stop trolling the forums and posting spam. It's not helpful and not wanted.
Bottom line: Don't like the Bioware database? Don't use it.
Funkyswerve has offered the community more than anything you ever have or will. If you've got a better solution then post it for everyone to use. Otherwise stop trolling the forums and posting spam. It's not helpful and not wanted.
Bottom line: Don't like the Bioware database? Don't use it.
#32
Posté 24 janvier 2012 - 02:00
FunkySwerve
-
- Members
- 1 308 messages
Lol, thanks for the eloquent defense, guys. I wonder if this is one of the clowns we banned. 
As far as the anti-Bioware-database rant goes, I'm not a huge fan of it either, which is why we use SQL.
Many developers out there, however, prefer the added simplicity of the bioware database, which is entirely sufficient for this purpose. Anyone who doesn't understand that development decisions like choice of database involve balancing alternatives and not black and white dichotomies, simply doesn't have any idea what they're talking about. Some developers don't want to invest the additional time required to learn how to make use of NWNX and nwnx_mysql. There are MANY legitimate, blindingly obvious reasons for such developers to opt for the native database solution - it's a simple question of zots. This is very easy to understand for anyone who's actually spent much time developing. And, in fact, you can find numerous discussions of the pros and cons out there. I've always advocated for learning NWNX/MySQL, but the simple fact is that there are a lot of devs out there that haven't, and their servers need protection as well.
As for calling my work sloppy and unprofessional....lolz. Perhaps he should post some of his own work to show all of us heathens exactly what we're doing wrong?
Some people...^^
Funky
As far as the anti-Bioware-database rant goes, I'm not a huge fan of it either, which is why we use SQL. Many developers out there, however, prefer the added simplicity of the bioware database, which is entirely sufficient for this purpose. Anyone who doesn't understand that development decisions like choice of database involve balancing alternatives and not black and white dichotomies, simply doesn't have any idea what they're talking about. Some developers don't want to invest the additional time required to learn how to make use of NWNX and nwnx_mysql. There are MANY legitimate, blindingly obvious reasons for such developers to opt for the native database solution - it's a simple question of zots. This is very easy to understand for anyone who's actually spent much time developing. And, in fact, you can find numerous discussions of the pros and cons out there. I've always advocated for learning NWNX/MySQL, but the simple fact is that there are a lot of devs out there that haven't, and their servers need protection as well.
As for calling my work sloppy and unprofessional....lolz. Perhaps he should post some of his own work to show all of us heathens exactly what we're doing wrong?
Some people...^^
Funky
#33
Posté 25 janvier 2012 - 02:32
ultima03
-
- Members
- 38 messages
FunkySwerve wrote...
Lol, thanks for the eloquent defense, guys. I wonder if this is one of the clowns we banned.
Many developers out there, however, prefer the added simplicity of the bioware database, which is entirely sufficient for this purpose. Anyone who doesn't understand that development decisions like choice of database involve balancing alternatives and not black and white dichotomies, simply doesn't have any idea what they're talking about. Some developers don't want to invest the additional time required to learn how to make use of NWNX and nwnx_mysql. There are MANY legitimate, blindingly obvious reasons for such developers to opt for the native database solution - it's a simple question of zots. This is very easy to understand for anyone who's actually spent much time developing. And, in fact, you can find numerous discussions of the pros and cons out there. I've always advocated for learning NWNX/MySQL, but the simple fact is that there are a lot of devs out there that haven't, and their servers need protection as well.
As for calling my work sloppy and unprofessional....lolz. Perhaps he should post some of his own work to show all of us heathens exactly what we're doing wrong?
Some people...^^
Funky
ultima03 wrote...
Why natural bioware database is not reliable, and why no dev should offer a solution using it :
- Limited to 32 chars, brutally truncated if longer
-
Var name must be unique throughout the entire database no matter if it
is an int or a float, or a string... (if not, it will be simply crushed)
-
Getter and Setter for CampaignLocation are absolutly not reliable, the
database can get invalid if u change the area layout in the toolset (!)
-
Database grow big and fast because the data that you asked for deletion
will not be deleted but simply flagged as deleted. uglier : If you try
to modify an entry, instead of overriting it, it will make a new one and
flag this one as deleted.
- One last : it's a slow database solution.
Why
would funkyswerve or anyone serious provide a solution using this,
especially concerning a Security problem ? he should just delete it and
leave the one with mysql. Its just like the people from Avlis providing a
craft system with
bioware db, and next to it a mysql version, the first one can be thrown
directly to the bin.
Why would you provide a solution concerning anything, but in this special case ; security, with the bioware db system to back it up? Are you blind? Or clueless?
You say 'not everyone wants to nwnx + mysl so ima give them a bioware bd that will get corruptd with a ratio of 100%, but it's okay for them'.
You funny guy. Just remove it, plain and simple, and leave only the nwnx-mysql version of your pretention of a fix. Or simply delete all your work. You probably already have caused a lot of trouble out there with your flaws. And if not, atleast clean that code, and clean your room.
Modifié par ultima03, 25 janvier 2012 - 02:40 .
#34
Posté 25 janvier 2012 - 03:55
wyldhunt1
-
- Members
- 246 messages
Not a bug. Does not affect reliability as long as your code is correct.ultima03 wrote...
Why natural bioware database is not reliable, and why no dev should offer a solution using it :
- Limited to 32 chars, brutally truncated if longer
(Learn how to write code and code related issues will go away)
Does not break the database as long as you use unique var names, which you should do anyway.-
Var name must be unique throughout the entire database no matter if it
is an int or a float, or a string... (if not, it will be simply crushed)
(Learn how to write code and code related issues will go away)
Erm... "Getter and Setter"... If you alter an existing map, previous references to locations in that map may become invalid. This is not a bug. Properly structured code will check to ensure that locations are valid and have a fallback location in place for use in the event that a mod builder must change an existing area.-
Getter and Setter for CampaignLocation are absolutly not reliable, the
database can get invalid if u change the area layout in the toolset (!)
(Learn how to write code and code related issues will go away)
It is also very easy to empty the database and eliminate the bloat whenever you want.-
Database grow big and fast because the data that you asked for deletion
will not be deleted but simply flagged as deleted. uglier : If you try
to modify an entry, instead of overriting it, it will make a new one and
flag this one as deleted.
This is not a serious concern. It is also not a flaw that makes the database difficult to use or more prone to error.
Speed does not prevent proper and stable use. It is the easiest db solution and a popular one. Not everyone wants to go through the effort and learning curve of a SQL solution. PW's which use a minimal amound of DB calls have no reason to go through the extra effort for the speed of SQL. The default DB is plenty fast for basic db management.- One last : it's a slow database solution.
Because there is nothing wrong with the default db and a lot of people use it.Why
would funkyswerve or anyone serious provide a solution using this,
especially concerning a Security problem ? he should just delete it and
leave the one with mysql. Its just like the people from Avlis providing a
craft system with
bioware db, and next to it a mysql version, the first one can be thrown
directly to the bin.
100%? Really? If you have had this issue, I recommend that you learn how to use it. It is stable for any properly programmed solution, such as this one.Why would you provide a solution concerning anything, but in this special case ; security, with the bioware db system to back it up? Are you blind? Or clueless?
You say 'not everyone wants to nwnx + mysl so ima give them a bioware bd that will get corruptd with a ratio of 100%, but it's okay for them'.
You should do some reading and maybe learn to program in Aurora and study some basic db use so that you understand the issues before you troll the threads concerning them.Blah Blah Troll Blah Trouble Blah Blah My +3 Imaginary Pixel Sword Blah Troll
Modifié par wyldhunt1, 25 janvier 2012 - 03:58 .
#35
Posté 25 janvier 2012 - 04:54
Lightfoot8
-
- Members
- 2 535 messages
saying the NW DB has 100% failure is like saying while loops always give too many instruction errors. You are simply using it wrong.
#36
Posté 25 janvier 2012 - 05:16
FunkySwerve
-
- Members
- 1 308 messages
Lolz. Still waiting for you to show us your cleaned up version of my code, ultima03, so you can show all of us clueless noobs what we're doing wrong. Use the sql code, if you like, since you seem to have a slight distaste for the native database. Surely, there are multitudes of ways you can improve on it, what with it being so messy and unprofessional... Just make sure it works first, hmm? Your understanding of databases seems a little shaky.
Oh, and wlyde, very nice debunking, though you might've also pointed out that most of those errors could NEVER apply to the script posted in this thread. Even the most telling, speed, is completely undetectable in practice, and there's hardly any difference in speed between MySQL and NWN in reads, which are far and away the most common calls in this code. Of course, all of this will no doubt be lost on ultima, but it's worth saying for those who might be interested in using the code who might be deterred by his inane ramblings.
Oh, and ultima....thanks for the bumps!
Funky
Just make sure it works first, hmm? Your understanding of databases seems a little shaky. Oh, and wlyde, very nice debunking, though you might've also pointed out that most of those errors could NEVER apply to the script posted in this thread.
Even the most telling, speed, is completely undetectable in practice, and there's hardly any difference in speed between MySQL and NWN in reads, which are far and away the most common calls in this code. Of course, all of this will no doubt be lost on ultima, but it's worth saying for those who might be interested in using the code who might be deterred by his inane ramblings.Oh, and ultima....thanks for the bumps!
Funky
#37
Posté 25 janvier 2012 - 05:50
WhiZard
-
- Members
- 1 204 messages
ultima03 wrote...
You funny guy. Just remove it, plain and simple, and leave only the nwnx-mysql version of your pretention of a fix. Or simply delete all your work. You probably already have caused a lot of trouble out there with your flaws. And if not, atleast clean that code, and clean your room.
Do not be overly swayed by Knat's data storage system. He does make a database more user friendly and faster, but it also comes at a functional cost that can easily be exploited by those who like to crash servers. No solution is 100% without flaws.
#38
Posté 25 janvier 2012 - 03:59
FunkySwerve
-
- Members
- 1 308 messages
What has Knat's got to do with anything? It hasn't even been mentioned, least of all by the troll, who I doubt has even heard of it. Yes, it CAN be used with bioware's native system to expand capability, but the same could be said of some of the problems that can be caused by using different SQL engines - they're problems relevant to the databases, not to the security scripts discussed in this thread.
Likewise, if you want to see a serious discussion of NWNX-MySQL vs Bioware's native database, I'm always game, but there have been many such discussions in the past, which you should be able to find easily enough with a search.
Neither is an appropriate topic for this thread, however much I like the bumps.
Funky
Likewise, if you want to see a serious discussion of NWNX-MySQL vs Bioware's native database, I'm always game, but there have been many such discussions in the past, which you should be able to find easily enough with a search.
Neither is an appropriate topic for this thread, however much I like the bumps.
Funky
#39
Posté 25 janvier 2012 - 06:21
WhiZard
-
- Members
- 1 204 messages
FunkySwerve wrote...
What has Knat's got to do with anything?
Read many of Ultima's posts outside this forum (he does mention a very high regard to Knat's work). Also compare the list of Ultima's "shortcomings" with Knat's script comments concerning fixes. The two lists have a high level of correspondence.
#40
Posté 26 janvier 2012 - 02:21
FunkySwerve
-
- Members
- 1 308 messages
WhiZard wrote...
FunkySwerve wrote...
What has Knat's got to do with anything?
Read many of Ultima's posts outside this forum (he does mention a very high regard to Knat's work). Also compare the list of Ultima's "shortcomings" with Knat's script comments concerning fixes. The two lists have a high level of correspondence.
Ah, gotcha, thanks. Odd to have such high regard for someone who's most noteworthy scriptset is designed around something he professes to loathe.
Funky
#41
Posté 27 janvier 2012 - 03:20
ultima03
-
- Members
- 38 messages
I will provide a MSA Workaround of my own. It will use the same principles as the funkySwerve's system but will allow unlimited CD-KEY storage, I dont quite understand why he limited it to 7 especially for the mysql version, also will protect the user against some problems that I explain in the description. Database will be NBDE, wich is perfect and I also use a tokenizer (yes both systems are from Knat, so what, he's the best) wich mimics useful function that can be found in other powerful langages not available in aurora, like arrays (set, get, push, count, explode).
Not Funky
<3
Not Funky
<3
Modifié par ultima03, 27 janvier 2012 - 03:41 .
#42
Posté 27 janvier 2012 - 03:53
wyldhunt1
-
- Members
- 246 messages
I'm sure that you'll find the community considerably more welcoming if you begin adding to the community instead of throwing complaints and insults.
I, at least, welcome all alternate versions of security code as long as they are bug free.
At the very least, it may be handy for anyone using Knat's systems.
I, at least, welcome all alternate versions of security code as long as they are bug free.
At the very least, it may be handy for anyone using Knat's systems.
#43
Posté 27 janvier 2012 - 04:09
FunkySwerve
-
- Members
- 1 308 messages
Well, I can't say I'm surprised you don't understand. Perhaps this will shed some light, but given your inability to understand that many people use the native database (with and without Knat's), I'm not holding my breath. Here goes.
It was a considered balance. On the one hand, I wanted to keep the total character count under 64 so that people choosing to use their own MySQL databases with it could use VARCHAR(64) (a common pick for VARCHAR length, if you look at the default database that ships with NWNX). VARCHAR results in much faster searches than text fields.
On the other hand, was the lack of countervailing reasons not to do so. On our server, we have NEVER had a request to allow additional keys. 99.7% of our playernames use 3 keys or less. Only 5 accounts out of almost 26,000 use all 7:
Sort of a strange thing to question when you've been going on about the dangers of Bioware database bloat.
Funky
It was a considered balance. On the one hand, I wanted to keep the total character count under 64 so that people choosing to use their own MySQL databases with it could use VARCHAR(64) (a common pick for VARCHAR length, if you look at the default database that ships with NWNX). VARCHAR results in much faster searches than text fields.
On the other hand, was the lack of countervailing reasons not to do so. On our server, we have NEVER had a request to allow additional keys. 99.7% of our playernames use 3 keys or less. Only 5 accounts out of almost 26,000 use all 7:
mysql> select count(*) from pwdata where name like 'PlayernameKey%'; +----------+ | count(*) | +----------+ | 25940 | +----------+ 1 row in set (0.00 sec) mysql> select count(*) from pwdata where name like 'PlayernameKey%' and CHAR_LENGTH(val) > 26; +----------+ | count(*) | +----------+ | 95 | +----------+ 1 row in set (0.00 sec) mysql> select 95/25940; +----------+ | 95/25940 | +----------+ | 0.0037 | +----------+ 1 row in set (0.00 sec) mysql> select count(*) from pwdata where name like 'PlayernameKey%' and CHAR_LENGTH(val) = 62; +----------+ | count(*) | +----------+ | 5 | +----------+ 1 row in set (0.00 sec) mysql> select 5/25940; +---------+ | 5/25940 | +---------+ | 0.0002 | +---------+ 1 row in set (0.00 sec) mysql>
Sort of a strange thing to question when you've been going on about the dangers of Bioware database bloat.
Funky
#44
Posté 27 janvier 2012 - 04:19
henesua
-
- Members
- 3 855 messages
I suppose he is also unaware of the issue with NBDE and Linux. *shrugs* Some people need to run into walls in order to understand that they are there.
#45
Posté 27 janvier 2012 - 05:02
wyldhunt1
-
- Members
- 246 messages
NBDE doesn't work on Linux?
'Tis a wall I was unaware of... Although in this case, it may just be because I default to assuming that 'software' does not work on Linux...
'Tis a wall I was unaware of... Although in this case, it may just be because I default to assuming that 'software' does not work on Linux...
#46
Posté 27 janvier 2012 - 05:24
Lightfoot8
-
- Members
- 2 535 messages
wyldhunt1 wrote...
NBDE doesn't work on Linux?
'Tis a wall I was unaware of... Although in this case, it may just be because I default to assuming that 'software' does not work on Linux...
I do not know if the bug was ever fixed or not. In the linux version of the NW DB the Delete Campaing DB function did not work, Therefor NDBE ended up compounding the problem that it was trying to fix, as far as the linux client went.
Im with funky, It is funny that someone who says that the NW DB is 100% fail is suggesting a NW DB solution to the problem.
#47
Posté 27 janvier 2012 - 07:27
WhiZard
-
- Members
- 1 204 messages
Let's tie the discussion together. As bolded below, Ultima maintained a lack of trust in first come is owner security interpretation.
Balduvard replied that this would only happen if the account owner had never logged in to the server. Thus being a case of foreknowledge on behalf of the account stealer to know which server the account holder has not been to and will likely go to.
After his/her distaste of Funky's approach Ultima then wished to replicate the process only adding in NDBE and unlimited account keys.
However keeping the first to come is account holder interpretation, the NBDE usage is susceptible to data loss from server crashes (while the given database solution is not). This extends the possibility of impersonation (of any newcomers) to more than just foreknowledge, as the data from their initial login can be erased. Thus Ultima's fix does an even worse security job in regards to one of the "security problems" he/she had already indicated. Besides that, there doesn't seem to be any significant difference between the solution Ultima proposed and the standard database solution already posted.
ultima03 wrote...
Anyone can enter any account without knowing the password. Period. Now I can go and make a lot of companies laugh about this joke. If MSA has any security breach, bioware/atari must secure it as a priority or cut the entire traffic. And when the MSA falls like time to time before, after the timeout it shouldnt grant access to servers like it always did. Now you say that checking Account/Keys and password matching require client patch? And yes pretending that the first to enter an account is the legitimate owner as the workaround of that funky guy declare is completly wrong.
Balduvard replied that this would only happen if the account owner had never logged in to the server. Thus being a case of foreknowledge on behalf of the account stealer to know which server the account holder has not been to and will likely go to.
Balduvard wrote...
Oh, but wait, our player account protection does not actually end with the password. In order for such an attack to be successful, wherein the offender manages to log into a server before the proper owner of the account does, or tries to log into the server after the account owner has failed to set a password, they would have to possess the exact CD Key of the account owner. Why? Because in addition to offering password protection, each account is tied to a single CD Key (reference Funky's provided scripts) unless otherwise authorized (which the real account owner will immediately discover on their first login to the server, permitting a red flag to be brought to the attention of server admins to handle the offending CD/IP).
After his/her distaste of Funky's approach Ultima then wished to replicate the process only adding in NDBE and unlimited account keys.
ultima03 wrote...
I will provide a MSA Workaround of my own. It will use the same principles as the funkySwerve's system but will allow unlimited CD-KEY storage, I dont quite understand why he limited it to 7 especially for the mysql version, also will protect the user against some problems that I explain in the description. Database will be NBDE, wich is perfect and I also use a tokenizer (yes both systems are from Knat, so what, he's the best) wich mimics useful function that can be found in other powerful langages not available in aurora, like arrays (set, get, push, count, explode).
However keeping the first to come is account holder interpretation, the NBDE usage is susceptible to data loss from server crashes (while the given database solution is not). This extends the possibility of impersonation (of any newcomers) to more than just foreknowledge, as the data from their initial login can be erased. Thus Ultima's fix does an even worse security job in regards to one of the "security problems" he/she had already indicated. Besides that, there doesn't seem to be any significant difference between the solution Ultima proposed and the standard database solution already posted.
#48
Posté 27 janvier 2012 - 03:19
ultima03
-
- Members
- 38 messages
The MSA being down means that anyone can enter any account on any server.
The MSA workaround is an internal registration system, wich means your
account and your name can still be used on any other server.
No single developper have the obligation to be aware that this workaround even exist.
This workaround is based on a declaration wich states that 'the first one to
enter is the owner', this is the principle for any new
game/website/platform launching when the database is empty, this is not
the case for a 9+ years old game. I remain against workarounds, and
everyone should be.
It's just that general flaws that shouldnt be provided.
account name can consist of 35 characters, the limitation of variables name is 32. Its already a problem.
example in : SetCampaignString("PlayernameKey", GetPCPlayerName(oPC), sKeys);
Now
if someone wants change your code for any purpose at their discretion,
and to concatenate accname to something else it will easily exceed 32
chars with even shorter accnames.
Simple test :
Create a player account of 35 characters
ie : "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Now store 7 keys like you do under that account name :
ie : string sKeys="88888888|BBBBBBBB|AAAAAAAA|QQQQQQQQ|ZZZZZZZZ|VVVVVVVV|XXXXXXXX";
SetCampaignString("PlayernameKey", GetPCPlayerName(oPC), sKeys);
Now retrieve it with GetCampaignString("PlayernameKey", GetPCPlayerName(oPC));
And you get nothing but an empty string.
For
any future implementation or tweak by end-user, they shouldn't be
worried about problems with 32chars limitation and be free to
concatenate all they want for any purpose. Now even GetName(oPC) +
GetPCPlayerName(oPC) or public key variants is dangerous.
Maybe
disallow accounts with 32+ chars to even enter your server? That won't
solve the general problem vars which accept concatenations, various
object tags, resrefs, etc .
Now you store Keys under the account of the user without specifying it t to hold keys and nothing else.
ie : SetCampaignString("PlayernameKey", GetPCPlayerName(oPC), sKeys);
instead of somthing like : SetCampaignString("PlayernameKey", "KEYS"+GetPCPlayerName(oPC), sKeys);
Now if the end-user has already a system that store data on GetPCPlayerName(oPC), may it be a string, a float or anything at his discretion, it will simply be overitten. The varName must be unique throughout the entire database.
Let's say you store the string sKeys under sAccount, but the end-user also use to track the number of loggin under the very same sAccount variable name (wich is not string, but an int) : it will simply be overwitten and you will get unintented results.
Limited to 7 keys. Why not 4,2 keys?
What do you know about general needs of others server that you offer a
system, servers with heavy faction system hold easily dozen of keys per
public accounts.
There is one thing that I recognize atleast is
that you do not offer an NPC or a vocal command to allow new keys, that
would be a security breach. But you should also imply loudly that none
should use anything in their own implementation of your workaround but
activate an item with a unique power.
Also I'm still concerned about security with this system, because any log-out by any player can be done for and suspected to be to add a new key. So anyone can test the one who left and his account
Server crash? Not only data you will loose but also items, levels, experience etc.
Linux and Windows user should both use nwnx-mysql.
Windows and NBDE works without single problem and is easier to implement.
NBDE with Linux has an explicit functionnality problem, everyone knows it.
The MSA workaround is an internal registration system, wich means your
account and your name can still be used on any other server.
No single developper have the obligation to be aware that this workaround even exist.
This workaround is based on a declaration wich states that 'the first one to
enter is the owner', this is the principle for any new
game/website/platform launching when the database is empty, this is not
the case for a 9+ years old game. I remain against workarounds, and
everyone should be.
It's just that general flaws that shouldnt be provided.
account name can consist of 35 characters, the limitation of variables name is 32. Its already a problem.
example in : SetCampaignString("PlayernameKey", GetPCPlayerName(oPC), sKeys);
Now
if someone wants change your code for any purpose at their discretion,
and to concatenate accname to something else it will easily exceed 32
chars with even shorter accnames.
Simple test :
Create a player account of 35 characters
ie : "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Now store 7 keys like you do under that account name :
ie : string sKeys="88888888|BBBBBBBB|AAAAAAAA|QQQQQQQQ|ZZZZZZZZ|VVVVVVVV|XXXXXXXX";
SetCampaignString("PlayernameKey", GetPCPlayerName(oPC), sKeys);
Now retrieve it with GetCampaignString("PlayernameKey", GetPCPlayerName(oPC));
And you get nothing but an empty string.
For
any future implementation or tweak by end-user, they shouldn't be
worried about problems with 32chars limitation and be free to
concatenate all they want for any purpose. Now even GetName(oPC) +
GetPCPlayerName(oPC) or public key variants is dangerous.
Maybe
disallow accounts with 32+ chars to even enter your server? That won't
solve the general problem vars which accept concatenations, various
object tags, resrefs, etc .
Now you store Keys under the account of the user without specifying it t to hold keys and nothing else.
ie : SetCampaignString("PlayernameKey", GetPCPlayerName(oPC), sKeys);
instead of somthing like : SetCampaignString("PlayernameKey", "KEYS"+GetPCPlayerName(oPC), sKeys);
Now if the end-user has already a system that store data on GetPCPlayerName(oPC), may it be a string, a float or anything at his discretion, it will simply be overitten. The varName must be unique throughout the entire database.
Let's say you store the string sKeys under sAccount, but the end-user also use to track the number of loggin under the very same sAccount variable name (wich is not string, but an int) : it will simply be overwitten and you will get unintented results.
Limited to 7 keys. Why not 4,2 keys?
What do you know about general needs of others server that you offer a
system, servers with heavy faction system hold easily dozen of keys per
public accounts.
There is one thing that I recognize atleast is
that you do not offer an NPC or a vocal command to allow new keys, that
would be a security breach. But you should also imply loudly that none
should use anything in their own implementation of your workaround but
activate an item with a unique power.
Also I'm still concerned about security with this system, because any log-out by any player can be done for and suspected to be to add a new key. So anyone can test the one who left and his account
Server crash? Not only data you will loose but also items, levels, experience etc.
Linux and Windows user should both use nwnx-mysql.
Windows and NBDE works without single problem and is easier to implement.
NBDE with Linux has an explicit functionnality problem, everyone knows it.
Modifié par ultima03, 27 janvier 2012 - 06:54 .
#49
Posté 27 janvier 2012 - 11:06
Lightfoot8
-
- Members
- 2 535 messages
Ok, Lets see, Let me take this one piece at a time.
[quote]ultima03 wrote...
This workaround is based on a declaration wich states that 'the first one to
enter is the owner', this is the principle for any new
game/website/platform launching when the database is empty, this is not
the case for a 9+ years old game.... [/quote]
Any server that has been around for 9+ years should have a backlog of server logs that contain the Public CD-Keys that have been used for any given account. A server admin who has been around for 9+ years should have no problem prpouplating there DB with valid CD-Kyey that have been used when the MSA was still up. If the server Admin has deleted there server logs, Well that was just a poor judgment call.
[quote]I remain against workarounds, and
everyone should be.
It's just that general flaws that shouldnt be provided.[/quote]
Well I guess you are intitled to the opinion. And us giving you the reasons what the MSA was never a good security system to begin with is is not going to change you mind now if it did'nt before
[quote]account name can consist of 35 characters, the limitation of variables name is 32. Its already a problem....[/quote]
Well you are a bit off on how long the account names can be. I think SkyWing recently stated the the limit for the protocall is 80 characters. I have made them up to 70 characters long just for testing. Cancatenating the names to 32 characters will work just fine. Agreed an oversite by funky, most likely due to the fact that he has not used the NW DB in years. with the names concatenated to 32 characters, It will just mean that all accounts will have to have the first 32 characters unique.
[quote]
Now
if someone wants change your code for any purpose at their discretion,
and to concatenate accname to something else it will easily exceed 32
chars with even shorter accnames.[/quote]
True, But why would they want to do that. I see no need, For any reason.
[Quote]
For
any future implementation or tweak by end-user, they shouldn't be
worried about problems with 32chars limitation and be free to
concatenate all they want for any purpose. Now even GetName(oPC) +
GetPCPlayerName(oPC) or public key variants is dangerous.[/quote]
Again, What is the point of adding to the var name. It pertains to one account, Not to one player in the account.
[quote]Maybe
disallow accounts with 32+ chars to even enter your server? That won't
solve the general problem vars which accept concatenations, various
object tags, resrefs, etc .
Now you store Keys under the account of the user without specifying it t to hold keys and nothing else.
ie : SetCampaignString("PlayernameKey", GetPCPlayerName(oPC), sKeys);
instead of somthing like : SetCampaignString("PlayernameKey", "KEYS"+GetPCPlayerName(oPC), sKeys);
Now if the end-user has already a system that store data on GetPCPlayerName(oPC), may it be a string, a float or anything at his discretion, it will simply be overitten. The varName must be unique throughout the entire database.
[/quote]
That would not happen, Unless of cource the end-user just happened to already be using a DB with the name
PlayernameKey" as there DB. Of was folish enough to change the name of this DB to the one they are alrady using to store other stuff. They should leave this DB for storing CD-Keys and nothing else. all the problems you just named just went away. Or do you think a module is restricted to having just one DB that it can access?
[quote]Let's say you store the string sKeys under sAccount, but the end-user also use to track the number of loggin under the very same sAccount variable name (wich is not string, but an int) : it will simply be overwitten and you will get unintented results.[/quote]
It should not be placed into this DB. Use another DB name of storing that information, If not you are just asking for trouble.
[quote]Limited to 7 keys. Why not 4,2 keys?
What do you know about general needs of others server that you offer a
system, servers with heavy faction system hold easily dozen of keys per
public accounts.[/quote]
I guess if you do not know the general needs of other you should just not try and help anyone. If not someone will come along and start saying that your scripting is not worth a dam because you only solved the problems of 99% of the people. The other 1% just want to gripe instead of asking for help, I guess.
[quote]There is one thing that I recognize atleast is
that you do not offer an NPC or a vocal command to allow new keys, that
would be a security breach. But you should also imply loudly that none
should use anything in their own implementation of your workaround but
activate an item with a unique power.[/quote] I do not see how funky can be held accountable for any modifications any decides to make to it. I also Do not see your security breach from spoken commands. The PlayerChat commands are easily removed for any prying ears, As long as you know what you are doing. Anyone writing such a script should know enough to take the need procations. It is there responcibility to know what they are doing if they make modifications.
[quote]Also I'm still concerned about security with this system, because any log-out by any player can be done for and suspected to be to add a new key. So anyone can test the one who left and his account[/quote]
And the player will know it and be able to report it.
[quote]Server crash? Not only data you will loose but also items, levels, experience etc.[/quote]
Umm You lost me, What does this have to do with anything?
[quote]Linux and Windows user should both use nwnx-mysql.[/quote]
Every one has a right to chose based on there own reasons.
[quote]Windows and NBDE works without single problem and is easier to implement.
NBDE with Linux has an explicit functionnality problem, everyone knows it.
[/quote]
There is realy no differance. NBDE is just a wraper of the NWN DB to allow a few extras at the cost of a few things.
You have made one one valid point and that was the limit of 32 character for the NW BD, It is simple enough to just trim the account name to 32 characters, The problem is solved right there. Even if some one tries to create an account with 32 characters that are the same as someone elses, He will fail the validation and be required to create a new account. If such accounts already exsist on the server, unlikely but I guess it could happen, The server admin should have no prpblem moving the players to there new account.
[quote]ultima03 wrote...
This workaround is based on a declaration wich states that 'the first one to
enter is the owner', this is the principle for any new
game/website/platform launching when the database is empty, this is not
the case for a 9+ years old game.... [/quote]
Any server that has been around for 9+ years should have a backlog of server logs that contain the Public CD-Keys that have been used for any given account. A server admin who has been around for 9+ years should have no problem prpouplating there DB with valid CD-Kyey that have been used when the MSA was still up. If the server Admin has deleted there server logs, Well that was just a poor judgment call.
[quote]I remain against workarounds, and
everyone should be.
It's just that general flaws that shouldnt be provided.[/quote]
Well I guess you are intitled to the opinion. And us giving you the reasons what the MSA was never a good security system to begin with is is not going to change you mind now if it did'nt before
[quote]account name can consist of 35 characters, the limitation of variables name is 32. Its already a problem....[/quote]
Well you are a bit off on how long the account names can be. I think SkyWing recently stated the the limit for the protocall is 80 characters. I have made them up to 70 characters long just for testing. Cancatenating the names to 32 characters will work just fine. Agreed an oversite by funky, most likely due to the fact that he has not used the NW DB in years. with the names concatenated to 32 characters, It will just mean that all accounts will have to have the first 32 characters unique.
[quote]
Now
if someone wants change your code for any purpose at their discretion,
and to concatenate accname to something else it will easily exceed 32
chars with even shorter accnames.[/quote]
True, But why would they want to do that. I see no need, For any reason.
[Quote]
For
any future implementation or tweak by end-user, they shouldn't be
worried about problems with 32chars limitation and be free to
concatenate all they want for any purpose. Now even GetName(oPC) +
GetPCPlayerName(oPC) or public key variants is dangerous.[/quote]
Again, What is the point of adding to the var name. It pertains to one account, Not to one player in the account.
[quote]Maybe
disallow accounts with 32+ chars to even enter your server? That won't
solve the general problem vars which accept concatenations, various
object tags, resrefs, etc .
Now you store Keys under the account of the user without specifying it t to hold keys and nothing else.
ie : SetCampaignString("PlayernameKey", GetPCPlayerName(oPC), sKeys);
instead of somthing like : SetCampaignString("PlayernameKey", "KEYS"+GetPCPlayerName(oPC), sKeys);
Now if the end-user has already a system that store data on GetPCPlayerName(oPC), may it be a string, a float or anything at his discretion, it will simply be overitten. The varName must be unique throughout the entire database.
[/quote]
That would not happen, Unless of cource the end-user just happened to already be using a DB with the name
PlayernameKey" as there DB. Of was folish enough to change the name of this DB to the one they are alrady using to store other stuff. They should leave this DB for storing CD-Keys and nothing else. all the problems you just named just went away. Or do you think a module is restricted to having just one DB that it can access?
[quote]Let's say you store the string sKeys under sAccount, but the end-user also use to track the number of loggin under the very same sAccount variable name (wich is not string, but an int) : it will simply be overwitten and you will get unintented results.[/quote]
It should not be placed into this DB. Use another DB name of storing that information, If not you are just asking for trouble.
[quote]Limited to 7 keys. Why not 4,2 keys?
What do you know about general needs of others server that you offer a
system, servers with heavy faction system hold easily dozen of keys per
public accounts.[/quote]
I guess if you do not know the general needs of other you should just not try and help anyone. If not someone will come along and start saying that your scripting is not worth a dam because you only solved the problems of 99% of the people. The other 1% just want to gripe instead of asking for help, I guess.
[quote]There is one thing that I recognize atleast is
that you do not offer an NPC or a vocal command to allow new keys, that
would be a security breach. But you should also imply loudly that none
should use anything in their own implementation of your workaround but
activate an item with a unique power.[/quote] I do not see how funky can be held accountable for any modifications any decides to make to it. I also Do not see your security breach from spoken commands. The PlayerChat commands are easily removed for any prying ears, As long as you know what you are doing. Anyone writing such a script should know enough to take the need procations. It is there responcibility to know what they are doing if they make modifications.
[quote]Also I'm still concerned about security with this system, because any log-out by any player can be done for and suspected to be to add a new key. So anyone can test the one who left and his account[/quote]
And the player will know it and be able to report it.
[quote]Server crash? Not only data you will loose but also items, levels, experience etc.[/quote]
Umm You lost me, What does this have to do with anything?
[quote]Linux and Windows user should both use nwnx-mysql.[/quote]
Every one has a right to chose based on there own reasons.
[quote]Windows and NBDE works without single problem and is easier to implement.
NBDE with Linux has an explicit functionnality problem, everyone knows it.
[/quote]
There is realy no differance. NBDE is just a wraper of the NWN DB to allow a few extras at the cost of a few things.
You have made one one valid point and that was the limit of 32 character for the NW BD, It is simple enough to just trim the account name to 32 characters, The problem is solved right there. Even if some one tries to create an account with 32 characters that are the same as someone elses, He will fail the validation and be required to create a new account. If such accounts already exsist on the server, unlikely but I guess it could happen, The server admin should have no prpblem moving the players to there new account.
Modifié par Lightfoot8, 27 janvier 2012 - 11:10 .
#50
Posté 28 janvier 2012 - 01:43
FunkySwerve
-
- Members
- 1 308 messages
Actually, the 32 char limit isn't a problem, as lightfoot points out - the person would be blocked. We have a grand total of 487 of those 26k playernames that exceed 32 chars, and have NEVER had a complaint about an accidental overlap. And, of course, if an overlap wasn't accidental, it would be blocked, as lightfoot notes.
Likewise, the assumption about the legitimate account holder being the first to log in has also NEVER failed, as has already been noted in the thread.
What ultima simply doesn't grasp is something that is obvious to experienced coders. ANY good code is a series of compromises. You COULD choose to maximize your code's speed, for example, but to do so you would have to make extreme sacrifices in readability and modularity. The best code is, generally speaking, that which looks at the costs associated and balances them to maximize benefit vs cost. The concept is related to that of diminishing marginal returns, or, more colloquially, 'too many cooks in the kitchen'. See, e.g.,
http://en.wikipedia....nishing_returns
That principle is why it is so monumentally stupid to insist that people shouldn't use code simply because it has hypothetical shortcomings which almost never obtain in practice, and which are low-cost to fix should they actually come to pass. No one with any reasonable amount of coding experience would make this kind of claim...as has been made abundantly clear by all the experienced coders posting above.
And to those coders...thank you for your time spent debunking - I can ill-afford the time to do it myself if I can help it.
Funky
Likewise, the assumption about the legitimate account holder being the first to log in has also NEVER failed, as has already been noted in the thread.
What ultima simply doesn't grasp is something that is obvious to experienced coders. ANY good code is a series of compromises. You COULD choose to maximize your code's speed, for example, but to do so you would have to make extreme sacrifices in readability and modularity. The best code is, generally speaking, that which looks at the costs associated and balances them to maximize benefit vs cost. The concept is related to that of diminishing marginal returns, or, more colloquially, 'too many cooks in the kitchen'. See, e.g.,
http://en.wikipedia....nishing_returns
That principle is why it is so monumentally stupid to insist that people shouldn't use code simply because it has hypothetical shortcomings which almost never obtain in practice, and which are low-cost to fix should they actually come to pass. No one with any reasonable amount of coding experience would make this kind of claim...as has been made abundantly clear by all the experienced coders posting above.
And to those coders...thank you for your time spent debunking - I can ill-afford the time to do it myself if I can help it.
Funky
