100 réponses à ce sujet

[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?

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

[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!!!

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

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

[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

[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

[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

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

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

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

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

[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

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

[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

[Sadira of Tyr]

Thank you Funky.

[FunkySwerve]

Here's a sample modification of VerifyPlayernameAgainstCDKey that handles the Good Old Games public cd key:

int VerifyPlayernameAgainstCDKey(object oPlayer) {
    int nBoot = FALSE;
    string sUnencoded = GetPCPlayerName(oPlayer);
    string sPlayer = SQLEncodeSpecialChars(sUnencoded);
    string sKey = GetPCPublicCDKey(oPlayer);
    string sStoredKey, sAddingKey;
    string sSQL = "SELECT val, tag FROM pwdata WHERE name='PlayernameKey" + sPlayer + "'";
    object oMessenger = GetMessenger();
    SQLExecDirect(sSQL);

    /* there's at least one key stored already */

    if (SQLFetch() == SQL_SUCCESS) {
        sStoredKey = SQLGetData(1);
        sAddingKey = SQLGetData(2);

        /* they indicated that they wanted to add a key this login */

        if (sAddingKey == "Adding") {

            /* their current key is not in the key string, add it unless at 7 keys already */
            if (FindSubString(sStoredKey, sKey) == -1) {
                int nKeyLength = GetStringLength(sStoredKey);

                if (sKey == "Q7RREKF3") {

                    DelayCommand(19.0, FloatingTextStringOnCreature("WARNING! You are using a public cd key from GoG. Check your chat log for more information", oPlayer, FALSE));
                    DelayCommand(20.0, SendChatLogMessage(oPlayer, COLOR_RED +
                "We do not store the public key provided by Good Old Games, because it would allow anyone with that key to log in to your account. The key will not be added to your list of allowed cd keys." + COLOR_END, oMessenger));

                    /* must mark as no longer adding */
                    sSQL = "UPDATE pwdata SET tag='Set' WHERE name='PlayernameKey" + sPlayer + "'";
                    SQLExecDirect(sSQL);

                } else if (nKeyLength > 61) { /* allow 7 keys max key-key-key-key-key-key-key    6 spacers + 7x8 keys = 62 */
                    nBoot = TRUE;

                    /* must mark as no longer adding */
                    sSQL = "UPDATE pwdata SET tag='Set' WHERE name='PlayernameKey" + sPlayer + "'";
                    SQLExecDirect(sSQL);

                    /* add the key to the string */
                } else {
                    sSQL =
                        "UPDATE pwdata SET tag='Set',val='" + sStoredKey + "-" + sKey + "' WHERE name='PlayernameKey" + sPlayer +
                        "'";
                    SQLExecDirect(sSQL);
                    DelayCommand(25.0, FloatingTextStringOnCreature("New CD Key Successfully Added!", oPlayer, FALSE));
                }


                /* let them know they already had this key in their string */
            } else {
                DelayCommand(25.0,
                    FloatingTextStringOnCreature("CD Key Addition Failed! This key already listed for this account!", oPlayer,
                        FALSE));

                /* must mark as no longer adding */
                sSQL = "UPDATE pwdata SET tag='Set' WHERE name='PlayernameKey" + sPlayer + "'";
                SQLExecDirect(sSQL);
            }


            /* they are not adding, and the cd key doesnt match those listed - boot and log */
        } else if (FindSubString(sStoredKey, sKey) == -1) {
            string sReport = "INCORRECT CD KEY DETECTED! ID: " + sUnencoded + "; Name: " +
                GetName(oPlayer) + "; CD Key: " + sKey + "; IP: " + GetPCIPAddress(oPlayer) +
                ":" + IntToString(GetPCPort(oPlayer));

            WriteTimestampedLogEntry(sReport);
            SendMessageToAllDMs(sReport);
            SendMessageToPCDMs(sReport);
            SendMessageToPCAdmins(sReport);

            nBoot = TRUE;
        }


        /* new account, add the key */

    } else {
        if (sKey == "Q7RREKF3") {
            DelayCommand(19.0, FloatingTextStringOnCreature("WARNING! You are using a public cd key from GoG. Check your chat log for more information", oPlayer, FALSE));
            DelayCommand(19.5, SendChatLogMessage(oPlayer, COLOR_RED +
                "Everyone who buys a copy of NWN from Good Old Games gets the cd key you are using. This can cause many problems, including an inability to log in whenever anyone else is using the key. You should refer to our Installation Guide at http://wiki.hgweb.org/wiki/Installation_Guide for instrucitons on how to obtain a private cd key form GoG." + COLOR_END, oMessenger));
            DelayCommand(20.0, SendChatLogMessage(oPlayer, COLOR_RED +
                "We do not store the public key provided by Good Old Games, because it would allow anyone with that key to log in to your account. The key will not be added to your list of allowed cd keys, and anyone will be able to log in to your account, until you obtain a private key." + COLOR_END, oMessenger));
        } else {

            sSQL = "INSERT INTO pwdata (val,name) VALUES" + "('" + sKey + "','PlayernameKey" + sPlayer + "')";
            SQLExecDirect(sSQL);
        }
    }

    return nBoot;
}

Funky

[slappy_the_ringthief]

seems like a great system. I was just looking into this as I'm putting my server back up, after auth servers were closed.

Not to take anything away from this, but could a much simpler (but less robust) version simply write the cdkey onto the character persistently (nwnx2) and check using that and a much smaller script?

Just considering my options

[Lightfoot8]

slappy_the_ringthief wrote...

seems like a great system. I was just looking into this as I'm putting my server back up, after auth servers were closed.

Not to take anything away from this, but could a much simpler (but less robust) version simply write the cdkey onto the character persistently (nwnx2) and check using that and a much smaller script?

Just considering my options

THat would only lock a   character to a CD key.    It would not secure a players vault(USER NAME)   to the player.  

So if slappy_the_ringthief  was playing a thief one day, you would not know if it was the same player playing slappy_the_ringthief  the fighter the next.

[Squatting Monk]

That's easy to get around, of course.

The benefit of this system, though, is that you can link multiple CD keys to a player, and allow the player to add new ones. I've cooked up a slimmer system that uses a custom table. No string manipulation required to parse results.

[slappy_the_ringthief]

Lightfoot8 wrote...

slappy_the_ringthief wrote...

seems like a great system. I was just looking into this as I'm putting my server back up, after auth servers were closed.

Not to take anything away from this, but could a much simpler (but less robust) version simply write the cdkey onto the character persistently (nwnx2) and check using that and a much smaller script?

Just considering my options

THat would only lock a   character to a CD key.    It would not secure a players vault(USER NAME)   to the player.  

So if slappy_the_ringthief  was playing a thief one day, you would not know if it was the same player playing slappy_the_ringthief  the fighter the next.

True, I had not thought of it that way. My characters would be safe but not my identity

[slappy_the_ringthief]

What is the oMessenger stuff in the last one that doesn't compile? Am I dumb?

Modifié par slappy_the_ringthief, 18 décembre 2013 - 02:41 .

[Squatting Monk]

That's from SIMTools. You don't need to use that (or the SendChatLogMessage() function, which can be replaced with SendMessageToPC()). This is just an example of how Funky's server does it, not a canned one for other people's use.

Modifié par Squatting Monk, 18 décembre 2013 - 08:25 .

[Vincent07]

I implemented this system some time ago, before the exception for the generic GoG key was put in.

 

I now have a problem where there are a few accounts with that key bound to them.

 

Will adding that final else segment let them log in, or is there a further alteration that will be needed so they can at least log in until they get a new key?  ie: I need it to purge the GoG key from their entry.

[RustyNail]

Can anyone help me please, I am very Noob at scripting. And I am in the need of this script but I cant seem to get it to work properly.

 

if anyone is up to it I just need a script I can put in conversation with a NPC that's binds the cd key when they choose to answer yes.

 

I don't want the key to bind until they talk to the npc and do it manually, and multiple keys are not important since so few ppl will play my server.

 

 

Please please and thank you in advance for any help I can get