Everything is read-only and unauthenticated, so there is no security
risk. Hopefully this will allow some cool projects based on AJAX to be
developed.
Signed-off-by: Graham <gpe@openrs2.org>
This will allow us to import FunOrb caches without worrying about the
risk of collisions with the main set of RuneScape caches.
Signed-off-by: Graham <gpe@openrs2.org>
lo should've been masked rather than hi. I've switched the code to mask
both the low and high DWORDs for simplicity.
Signed-off-by: Graham <gpe@openrs2.org>
Useful for running directly on my server, which is headless Linux. (The
current extract tool is a GUI Windows app.)
Signed-off-by: Graham <gpe@openrs2.org>
It removes the archive/group prefix and the 0xFF markers.
Unfortunately using Js5ResponseDecoder here is tricky - perhaps it
could've been done with an EmbeddedChannel.
Signed-off-by: Graham <gpe@openrs2.org>
Keys are now initially imported into a key_queue table, which is never
locked exclusively - allowing the API endpoint to function while the
brute forcer is running. The brute forcer moves all pending keys in the
queue to the keys table before running the actual brute forcing.
Signed-off-by: Graham <gpe@openrs2.org>
Streaming .tar.gz files requires less memory, as we don't need to
remember metadata about each file for the end of directory record.
Signed-off-by: Graham <gpe@openrs2.org>
There are two main reasons for this change: by default, logback uses
stdout (!) and not stderr. This caused problems in programs like
packclass/unpackclass, where the packclass or JAR files were mixed in
with Netty's debug logging.
Secondly, the debug logging from lots of third-party libraries was
annoying (as it made it difficult to pick out OpenRS2-specific log
messages), so I've disabled lots of it.
Signed-off-by: Graham <gpe@openrs2.org>
I'm still not particularly happy with this: if the JS5 download
finishes before HTTP, it'll time out and kill the whole process.
Similarly, because it takes so long to import the indexes and as we
can't fetch groups in parallel with that, it can often time out early
during the process.
In the long term, I think I am going to try and move most of the logic
outside of the Netty threads and communicate between threads with queues
or channels. This would also allow us to run multiple JS5 clients in
parallel.
The code also needs some tidying up, particularly constants in the
Js5ChannelHandler constructors.
Signed-off-by: Graham <gpe@openrs2.org>
