Securing Your Server Without Master Server Authentication

[Legacy_HUNTER_of_Wisdom]

               Hello, Lightfoot8
I'll try it here.
but tell me one thing, if I want to drive to a DB on my FTP server, could I?

If yes, how?
               
               

               
            

[Legacy_Lightfoot8]

               

HUNTER_of_Wisdom wrote...

Hello, Lightfoot8
I'll try it here.
but tell me one thing, if I want to drive to a DB on my FTP server, could I?

If yes, how?

The inly thing the .bat file does is write a NW source Script.    If your NWN can write to your FTP server, then sure.  Just open the Script up in the Toolset script editor and make any adjustments you need to make.
               
               

               
            

[Legacy_Thayan]

               Awesome Lightfoot! Using that script to create entries in the database for every single folder in the servervault, and then putting your fix/addition in the initial validation script works like a charm for me in my test environment for both a new playername and using an already existing name. The only thing I'm considering changing is letting the person actually login if their CD Key validation checks out, setting them to Uncommandable, and sending them a message to login using the case sensitive name stored for them to try and avoid confusion around why someone is getting booted when trying to login. Either way though, I'll be implementing this on our live server very soon.

A mug of ale to you for the bat file and addition to the script. THANKS!!!
               
               

               
            

[Legacy_HUNTER_of_Wisdom]

               Hello friend,
hey dude, i do not disturbe, but very weak in nwn BD, can you help me?
Can you give the tutorial Implemented to this? I mean from the beginning? even if I create and how a table in my DB ....
Sorry to this, but i need the your help in this.
I know, you help so much, and I so very happy to this.
Thanks to your help, Guy.
               
               

               
            

[Legacy_Chokra Broodslayer]

               Thanks for creating these scripts. Our Broodslayers server (which is currently inactive due to the EF-5 of 2011, which destroyed my home and car), is being rebuilt. We were on a Linux server and implemented the BioWare database back when that was the ONLY choice. We looked into NWNx after it released but when we first looked at it, it wasn't compatible with Linux. Since our old server wasn't fast enough and I didn't want to buy another copy of XP, we stayed with the BioWare database and never had any issues with it, for storing persistence, storage chests, PC location, creature loot drop options, quest persistence, etc. Later, we decided to switch to NWNx after the Linux support was available but weren't sure how to move the existing database info over to the NWNx, as well as how to rework the entire module (which was in excess of 150 areas by that point).

As we rebuild the PW (overhaul), security will be an issue. I have recovered the hard drive for the old server, from the rubble, and have managed to save the database file and mod file and everything else.

It will probably be 2013 before there's anything available to host.
               
               

               
            

[Legacy_FunkySwerve]

               Thanks to all who have been helping to keep up this thread during my absence. I got a number of pm's about a case-sensitivity issue which doesn't exit - at least not with MySQL-Linux. Specifically, the concern was that a player could log into someone else's account by swapping out a lowercase letter for an uppercase, or vice versa.

None of the reports I received, however, mentioned seeing that player's characters, and one of them actually specifically says they are NOT there, so I figured it would be to good to post a clarification. All of what I'm about to say pertains only to MySQL-Linux. It SHOULD be true for other versions, but if it is not, I'd definitely like to hear about it. My experience with those other setups is simply too old for me to be sure, however. That caveat aside:

NWN treats playernames as case-sensitive. FunkySwerve and Funkyswerve are two totally different accounts. Having the server security script treat them as one would be inappropriate. This is actually a common point of confusion for our returning players, who can't figure out where all their characters went, and post asking if they've been deleted, when they're simply using the wrong playername because they forgot to capitalize something (or decapitalize it).

That said, NWN DOES have issue distinguishing identical player and character name combinations when dealing with local variables, requiring an entirely different anti-exp!0it code to cover certain situations if you allow players to delete characters. Those issues, however, are ALSO case-sensitive, so far as I know.

About the only other possible problem I can imagine is if your other databasing is failing to distinguish case sensitivity, which could lead to overlapping player/player-character database associations. That, however, is an issue with your approach to databasing, and not with this server security script.

As I said, if your experience varies from the above, and is not simply based on some confusion clarified above, I'd like to hear about it - either here, or in PM if you feel the issue requires some discretion.

Thanks,
Funky
               
               

               
            

[Legacy_FunkySwerve]

               Update: case-sensitivity is indeed an issue for Windows servers, but not for Linux servers. Thanks to Algernon's Ghost for helping to confirm.

You can fix it by using GetStringUpperCase or GetStringLowerCase to force all cases to either upper or lower. I'm amending the script in the initial post. Thanks to all who pointed this out.

Thanks,
Funky
               
               

               
            

[Legacy_FunkySwerve]

               In response to a question I got about what effect this would have on existing databased entries, well, they would no longer match. You would either need to wipe the table and start over, or update all the entries. With MySQL, at least, it's quite easy to update the entries. I'll use lowercase in this example, since that's what I picked for the posts on page 1, but you can just as easily do this with uppercase:

UPDATE table SET colname=LCASE(colname);

Just substitute 'table' for your table's name, and colname for the column name, and you're golden (that example sets them all to lowercase). UCASE is the function should you want to set them all to uppercase.

Funky
               
               

               
            

[Legacy_AlgernonsGhost]

               Using the free software, SQLite Database Browser, on a SQLite database the command to execute that converted all player name entries to lower case was (changing 'table' and both instances of 'colname' as Funky mentioned above):

UPDATE table SET colname=lower(colname);

SQLite apparently does not recognize the function LCASE, but uses lower(x) instead.
               
               

               

                     Modifié par AlgernonsGhost, 14 décembre 2012 - 09:30 .
                     
                  

            

[Legacy_FunkySwerve]

               LOWER and UPPER are alternate functions - though I didn't know that SQLite lacked the others. Please note that if you're using the SQL code exactly as it exists in the second post in this thread, you'll run into a problem with the simple UPDATE posted above, as the code expects PlayernameKey to have a capital P and K. You can either amend the code to lowercase those, or amend the UPDATE to something more complex, to preserve them.

Funky
               
               

               

                     Modifié par FunkySwerve, 14 décembre 2012 - 09:34 .
                     
                  

            

[Legacy_AlgernonsGhost]

               I went with changing the capital P and K instances in PlayernameKey to lower case in the OnEnter script since I had already run the simple UPDATE on my SQLite database.

I actually like that this fix effectively locks in all letter case variations of a player's ID to that one player, thus giving them a completely unique name on the server.

I've already tested this fix on a Windows XP server client with SQLite default database that comes/installs with NWNX2, and it's working perfectly.

Thank you Funky!
               
               

               

                     Modifié par AlgernonsGhost, 14 décembre 2012 - 10:02 .
                     
                  

            

[Legacy_maddogfarg0]

               

ultima03 wrote...

Non sql data storage is not reliable. (more like horrible)

Funky:.  Thanks for sharing.  I know you posted/mentioned these a long time ago but I set my NWN server aside for a while and am only now getting back into building.  I took a look to compare them to my own scripts and glad to know I'm on the right track with my authentication plan. 

Ultima03:  Your post quoted above is misinformation. 

I've been using the FoxPro based BioDB from day 1 for nearly 7 years now with absolutely 0 problems.  You just need to know how to maintain the database properly. 

Grab a DBF repacking tool and run it once every 60-90 days, or whenever your database files start to get large, and you'll be fine.  I personally use iLabMalta's inexpensive DBFpacker.  It works great, is fast, and can even be called from a scheduled job or script with instructions to repack an entire folder.  There may be a good freeware alternative out there as well.

SQL is better for certain applications, especially if you have more advanced needs shared across multiple servers.  But BioDB will work fine for these authentication scripts.
               
               

               

                     Modifié par maddogfarg0, 10 janvier 2013 - 04:40 .
                     
                  

            

[Legacy_FunkySwerve]

               I'm sort of in ultima's camp on that one, MDF. Even assuming all that you say is true - and I have no reason to doubt it or you - the bioware database is in this way to sql as windows is to linux - you have to do additional maintenance for no real gain (defrag in windows). Win 7 automated the process, at least.

One of the main advantages of the bioware database is its prepacked/user-friendly aspect, but having to use an external utility kills a lot of that - as you say, it requires additional knowedge. Given that, I can't really think of a reason to advocate for it over SQL, other than the inconvenience of having to transfer data from a user's old tables to new SQL tables.

Funky
               
               

               
            

[Legacy_Sadira of Tyr]

               Thank you for the scripts Funky. I'm going to try adding them into our module. However I have a couple questions.

The script for a dm to remove a cd key from a player account. Does that involve the dm using normal chat, or the console commands?

I like the idea about a five minute time for accepting a new cd key, but the solution posted did not give a version for the Bioware database. I am curious about one thing. If a player wants to add another cd key, and sets their account to recieve a new key, does this option close after the player relogs, or does it stay open until next server reset.

Sorry for the questions, but these scripts are hard for me to understand some of it.

Thank you.
               
               

               
            

[Legacy_FunkySwerve]

               

The script for a dm to remove a cd key from a player account. Does that involve the dm using normal chat, or the console commands?

Normal chat. Nothing I code uses the console commands.

If a player wants to add another cd key, and sets their account to recieve a new key, does this option close after the player relogs, or does it stay open until next server reset.

It closes as soon as they relog.

Funky