L2J Server

Hello!

I'm happy to announce the application I have been working on for the past year (or actually even longer).
oDrop is an open-source and free JavaScript-application for managing items (and possibly accounts and characters and much more later on) in Lineage 2 (up to High 5, but I think it'd be easy to make it work with GoD).
It runs basically in every webbrowser. However: I haven't tested anything besides IE8/IE9 and FF4+.
This application is written using GWT (Google Web Toolkit, a java-to-javascript-compiler and -framework) and Java (for backend). It runs on tomcat (I've tested it on version 7.0) and connects to the database using JNDI, meaning you can simply change the configuration in the "context.xml" and "web.xml" files, which you can find in the META-INF and WEB-INF folders.

In some cases you might also want to readjust the folders etc. Please note: some folder paths are still hardcoded, since this program is far from being done.

In fact: there is no binary version of the program just yet, but I think I might release a version that can be used without any debugging tools and without compilation very soon (probably in a week or two).

Currently the program can do the following:

• Login one or several accounts
• Show characters and let the user pick the characters he wants to work with
• Show the character-belongings
• Let the user filter the view by showing/hiding columns
• Let the user filter the view by choosing item properties (e.g.: show only items of certain grades)
• Let the user type in an item name or part of it in order to filter the output (e.g.: "adena" would return all items containing that string)
• Supports multiple languages (easily translatable using property-files; the application needs to be recompiled afterwards though; currently I include localization for German and English)

As you can see it's not much, but it's a solid base that one can work on. I tried to design everything as generic as possible in order to reuse as much as possible. The backend (the "services") already support displaying recipes, characters and skills. However: since I've rewritten a lot of oDrop when I migrated to GWT 2.1, these services are not yet used.

Oh - before I forget it: this program is not meant to be used in productive environments just yet, as I'm not sure about its security. While I have sessions working, I still didn't manage to actually let the program check every now and then whether the user is allowed to do what he does. I will work on this once I'm done with recipes and characters/character-details.

Below you can find a few screenshots of this application. Since it's basically a Javascript file, it can be made to appear on any page and since it does not need reloading (all data is fetched asynchronously using AJAX and GWT-RPC) you won't have any trouble. The only thing is that you do need to login as of now - there is no way around it (at the moment). This may be awkward if your user already logged in into your website.


If you want to help, feel free to drop by on https://code.google.com/p/odrop/.

Things that need to be done before this program may be used in production environment:

• Check and probably fix security issues concerning the rather weak login system
• Preferably, though not essential: write JUnit-tests (sorry - I was too lazy for that)
• Check compatibility with the other major browsers (Chrome, Opera and Safari)
• Get L2J-owners permission to distribute the Skill- and Item-XML files along (at the moment you will have to get both the item- and skill-xml files (#####-#####.xml) yourself and put them into the corresponding resource-folders)
• Find out if it'd be okay to distribute the icon-images of skills and items along with this program (currently you will have to get them yourself using whatever means)
• And finally: create a binary package that is easy to setup and upload to a tomcat-enabled environment

I'm sorry that there is no binary version at the moment, but if you're really eager and have the knowledge, you may checkout the project using SVN and try it on your own. When I'll have some more time on my hands, I might write a wiki-page on that project-page I linked earlier at some point.
Basically you will need the GWT 2.4 SDK and some knowledge to get this project up and running.

This application will be distributed under GPLv3 license. All files (except third-party-files) - even those that lack the license-header - fall under GPLv3 license. If you checkout this project or use the binary files later, you agree to the license.

I'll be updating this thread as I progress.

See you soon and have a nice day!
Hyrelius.

P.s.: in theory this program would even be able to run on HTML5-enabled phones, but - amongst many other things - I didn't yet test it.

P.s.2: Dear Admins and Moderators: if this topic by any means offended you or broke the rules, please tell me so I can fix it. I do not have any bad intentions, I just want to contribute to a game/game system that I've been playing for about 7 years now. Thank you!

As far as the screenshots go (though there isn't really much to see atm), it looks really nice. Good work!

L2J-owners?

Oh XD I'm sorry .. it was late and I kinda couldn't express myself as I wanted to...

Of course I didn't mean to say "L2J-owners", but L2J-staff, who'd tell me if it was alright to offer those XMLs along with my program. Though of course I'd recommend for the one who'd install this program on their server to put their own XML-files (from their server) into the respective folders. The reason is that the custom skills or (server-side) items would be recognized too, since all the XML files are parsed when the Java-(backend-)application is started.

The whole project is under GPLv3.0 you already have permission to use it completely or partially, you may refer to http://www.gnu.org/copyleft/gpl.html for more info on how to do it, but in short words you need a compatible licence with GPL v3.0 or later versions.

Maybe if ThePhoenixBird has some time he could bring more (fire?) light into this topic, but I think that expressing that you are using this project partially and keeping original licence for those files should be enough, and the right thing to do.

Good luck and I hope it stay open-source

Thanks Zoey! My project (oDrop) is under GPLv3 too and will stay that way! Therefore it's awesome news to me - I'm not too familiar with licenses, but judging from what I read I think I've chosen the correct one - all the more if both? projects are shared under the same license.

Sounds interesting.. keep up the good work

As we're drawing near the end of January, I'm trying to fix the most important things and release a binary version of this tool. I've been testing a compiled version of it on my tomcat server for a week now and I ended up improving this and that.

I've just finished a "delayed login"-system, meaning that while the "login"-request is sent each time, the actual "logging into an account" is done only if certain conditions are met.
A user basically has 3 login attempts for one account right away without any delays. If all 3 fail (because of a wrong password), the fourth attempt is delayed by 60 seconds (the user is asked to retry in 60 seconds - it's not yet displaying it at the moment, but it already considers it). If the fourth attempt fails too - the user is asked to wait for 120 seconds and the waiting-penalty increases several times.
Once the user fails the 10th time - the account is permanently banned and only a user-admin will be able to reset this.

In order to keep track of the last correct and wrong IPs and dates as well as failedLogins-count and the flag whether the user is permanently banned or not, I use a separate table called "odrop_accounts". Generally if say the user attempts to login at ODrop for the first time (given you've set up everything correctly), ODrop (server-part) checks whether the username exists in the l2j_game.accounts-table. If it does - it creates an empty recordset in the odrop_accounts-table. Then it runs its permission checks and finally returns a LoginDTO-state object, which contains information about the login status (including the corresponding AccountDTO if the login attempt was successful).

I have to implement "salt" into the password. Currently the password the user enters on the client side is hashed on the client using SHA1 and base64 (in the end I get the same hash as L2J-server does). What I want to add is a "pre-login"-request, which gives me a randomly generated salt-string. This salt-string will only be valid for just one login-attempt. Then the client would somehow use the salt in order to additionally protect the password and - that's the main purpose - essentially render rainbow tables useless. The server would apply the salt it has memorized the same way the client did in order to compare the passwords.

I'm not using SSL at the moment as I don't really think that I need this much security. I might add support for this at a later point if there is demand.

On https://code.google.com/p/odrop/updates/list you can see the change-list. Once I fixed that "salt"-issue and added a box displaying additional login-related information (on the login page - in order for the user to know how many times someone tried to login and when the last wrong and last correct logins were), I will make a binary (or rather: compiled) version of this application and submit it to the project page along with some instructions on how to get the program running.

Stay tuned .

Alright folks! Thank you for waiting .

Initial release

I've finally decided to compile a build and put it up on the net. I've also included some quick instructions on how to get ODrop up and running. If you have experience on deploying applications on tomcat, you won't have any trouble at all. If you don't, then the quick setup instructions should help you to deploy it there.

Yes, you need a tomcat setup. I have not tested it with any other servlet-container. I believe you could use apache with some mod-plugin, that allows running java-applications. And you could also incorporate the application within your CMS, but since I still think that you should NOT use this application in production mode, I haven't included any instructions on how to do so.

Basically you:
- download the file
- alter the settings to match your environment
- run the SQL-scripts (it adds the 'odrop_accounts' table into your l2j_game database)
- upload either the zip (prior to that you have to copy back the web.xml and context.xml files into the zip) or separate files into the ".../tomcat/webapps/<someFolderName>" directory

Get the file here: http://code.google.com/p/odrop/downloads/list and follow the instructions over there.

Note: uploading the ZIP file saves you bandwidth, since the ZIP-file is just about 20 megabyte, while the extracted release is about 110megabyte (lots of XML- and other text-data). Also I haven't included the icon-images, since I've gotten them from the client and didn't want to upload them (at least at the moment), but the application works well without them too. Might add them later to the build and SVN, but at the moment I'm not sure about the license and hence decided not to upload them.

Please report back your experience, suggestions and bugs (either on the project page on Google Projects or here). Also if you want to contribute, please get in touch with me . I'll set you up as contributor or developer! Non-members may checkout a read-only version of the SVN using "http://odrop.googlecode.com/svn/trunk/" as the path.

Thanks and enjoy!

EDIT: if someone could elaborate on how to access a l2j-server using telnet in order to add/remove items and such, I'd be grateful.. or at least tell me which classes or something to look at. I've gathered so far that it is not always enabled due to.. security risk? Is there any other approach besides telnet to add / remove an item? I don't need this right away, because all my program is currently doing is view the table contents - not alter it. But in a long shot I'd need this too.. thanks for your help in advance! .

To connect to telnet via PHP, might help get some ideas:
viewtopic.php?p=134619#p134619
For core classes go here: com\l2jserver\status and read the Game/LoginStatusThread classes.
Telnet commands are here: dist\game\data\scripts\handlers\telnethandlers
Add item command is in PlayerHandler.java, the command itself is in format "give charObjId itemId amount".
Also, you can only add an item via telnet if the player is online. Can be adapted to work offline aswell as long as the server is online, but you could also use the premium/vitamin item system or mail for this (but I'm totally not sure if it's supported by the core ATM).

Thanks jurchiks!

I've looked into it, but as far as I understood Telnet access can or even should be blocked on a production server? Therefore it won't work? I think it might be relatively easy to implement telnet access to the server etc., but I didn't do or even try it yet.

Other than that though: I've implemented an "Item list", which is basically the same as belongings, except that you get to browse through all items that are available on the server. NOTE: not all of those items are actually used on your server and some might be unachievable. However: as long as an item is introduced within one of the countless item-XML-files, it will appear in the list.
Again: you can filter and sort to your liking .

Here's my commit comment (copied from the SVN-commit description field, r59):
I added another service called "ItemLister", which is similar to the BelongingsService, except that it does not retrieve the items of one or more characters, but instead enables the user to browse through all items available on the server (all items that you can find in the item-XML-files). For this to work, I had to change quite a few things. Here's a short "changelog":
- refactored CellTableFilteringControls and CellTablePaginationControls to be entirely "Belongings"-independent
- added a new Constant-Type: ItemYesNo
- added new FilteringDTO (ItemListerFiltering and corresponding getter / setter) inside DataHolder
- initialize default FilteringDTO-settings in the static initializer of the DataHolder-class
- moved the addition of "FilterConditionsButton" to corresponding class (e.g. Belongings or ItemLister)
- added some simple escaping for the SearchBox input -> possible security issue!
- split item-loading-related event handling into its own eventhandler (ItemManageEvent) and successfully adjusted Belongings- and ItemLister-classes to work with the new eventhandler

I might have forgotten a few changes, but I think those up there are the most important ones.
ItemLister (item-list-browser) now appears under a third area called "Mobfinder". This one will contain stuff that you do not need to login for, e.g. item- and monster-browser as well as possibly some other stuff (such as a class and skill browser).

I haven't provided another compiled version though, because I think that it's not a significant feature-change (or at least not as significant), but anyone trying this out, is welcome to get in touch and help submit a version. When I added more features and made more changes and bugfixes, I'll submit another compiled version - probably at the end of February.

Cheers!

Just thought I'll let you know, that I'm still working on the application. However: after adding support to (in addition to the existing belongings-page) browse all items and NPCs from a server (and sort/filter them), I've caught myself having lots of duplicate and over-complex code. That's why I'll be working on changing the structure of the client-side (JavaScript) application in order to prevent writing code twice and having over-complex code.

The project consists of 3 main packages: client, server and shared. I'm pretty satisfied with everything inside the server-package and the shared-package only contains the model-objects, that will be moved between client and server (e.g. Recipe- or Item-information-objects). However: the client-side has (at the moment) 3 similar views (ItemLister, NPCLister and Belongings) and while they have a huge lot of functionality in common, they do not reuse a lot of methods, but have it implemented in their own classes - which is bad software architecture.

Once I've come up with a good (probably MVP-driven) solution, I'll alter all client-classes accordingly and compile another version for everyone who wants to test it. Just so you know this project is not dead - I find it interesting to learn more about the L2J-server by writing a managing tool.

dS.