Securing Your Server Without Master Server Authentication

[Legacy_zunath]

               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.
               
               

               
            

[Legacy_FunkySwerve]

               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
               
               

               
            

[Legacy_ultima03]

               

FunkySwerve wrote...

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

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 .
                     
                  

            

[Legacy_wyldhunt1]

               

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

Not a bug. Does not affect reliability as long as your code is correct.
(Learn how to write code and code related issues will go away)

-
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)

Does not break the database as long as you use unique var names, which you should do anyway.
(Learn how to write code and code related issues will go away)

-
Getter and Setter for CampaignLocation are absolutly not reliable, the
database can get invalid if u change the area layout in the toolset (!)

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.
(Learn how to write code and code related issues will go away)

-
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.

 It is also very easy to empty the database and eliminate the bloat whenever you want.
This is not a serious concern. It is also not a flaw that makes the database difficult to use or more prone to error.

- One last : it's a slow database solution.

 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.

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.

Because there is nothing wrong with the default db and a lot of people use it.

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'.

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.

Blah Blah Troll Blah Trouble Blah Blah My +3 Imaginary Pixel Sword Blah Troll

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.
               
               

               

                     Modifié par wyldhunt1, 25 janvier 2012 - 03:58 .
                     
                  

            

[Legacy_Lightfoot8]

               saying the NW DB has 100% failure is like saying while loops always give too many instruction errors.   You are simply using it wrong.
               
               

               
            

[Legacy_FunkySwerve]

               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
               
               

               
            

[Legacy_WhiZard]

               

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.
               
               

               
            

[Legacy_FunkySwerve]

               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
               
               

               
            

[Legacy_WhiZard]

               

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.
               
               

               
            

[Legacy_FunkySwerve]

               

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
               
               

               
            

[Legacy_ultima03]

               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>

               

                     Modifié par ultima03, 27 janvier 2012 - 03:41 .
                     
                  

            

[Legacy_wyldhunt1]

               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.
               
               

               
            

[Legacy_FunkySwerve]

               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:

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
               
               

               
            

[Legacy_henesua]

               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.
               
               

               
            

[Legacy_wyldhunt1]

               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... '>