Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (480)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (547)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  User Authentication  (Read 6738 times)
0 Members and 1 Guest are viewing this topic.
Offline in_the_end

Junior Newbie





« Posted 2007-03-16 18:30:25 »

I have read the tutorial provided by the latest release of SGS, but i couldn't find any guidelines related for defining a custom authenticator. However, there is a line in the client tutorial indicating that there may be a authenticator writing manual.

on page 6:
Writing and using custom authenticators will be covered in the SGS Stack Extension Manual.

Can anyone tell me where can i download that manual, please?
Can anyone guide me how to write a custom authenticator, please?
Thanks in advance.
Offline Jeff

JGO Coder




Got any cats?


« Reply #1 - Posted 2007-03-16 19:55:07 »

I'm writing it right now.  Ergo the tense of the sentence Wink

Its due for release at JavaOne in about 7 weeks to coincide with the Open Source release.

In the meantime if there are specific questions I can answer pls feel free to ask.

("How do i write an authenticator" is a general question, not a specific one Wink )


JK

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #2 - Posted 2007-03-16 21:29:19 »

Hi

This is all undocumented so far, but the interface you want to implement for custom authentication is com.sun.sgs.auth.IdentityAuthenticator, you'll need to add your implementation class to your application properties file. e.g.

com.sun.sgs.app.authenticators=com.sun.sgs.impl.auth.NamePasswordAuthenticator

That will give you the password file implementation that comes with SGS. You can use com.sun.sgs.impl.auth.PasswordFileEditor to create a password file. The file needs to go in your data dir for your application and be called passwords. I suspect there is a property to be able to change that, but i've not worried enough to look Smiley

HTH

Endolf

edit: com.sun.sgs.impl.auth.NamePasswordAuthenticator.PasswordFile i think is the property to change the path to your password file if you wish to change it Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline in_the_end

Junior Newbie





« Reply #3 - Posted 2007-03-17 17:14:29 »

Thanks for the reply, i will try to code it by following this:

com.sun.sgs.app.authenticators=com.sun.sgs.impl.auth.NamePasswordAuthenticator
Offline Jeff

JGO Coder




Got any cats?


« Reply #4 - Posted 2007-03-17 18:17:40 »

Curse you red baron!

 Grin


Seriously though, good detective work.  Just keep in mind that details we haven't published yet are free to change until we do.

Now... can you find the hidden profiling code?   Wink



Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #5 - Posted 2007-03-17 18:44:18 »

Aaaah, thats what the profile package is about, I saw it and wondered what it was Smiley

You got me interested now Tongue

Endolf

Offline Jeff

JGO Coder




Got any cats?


« Reply #6 - Posted 2007-03-17 19:00:59 »

Its very early, there is still a  LOT we intend to add to it.  Still, if you can figure out how to turn it on it could be useful Wink

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #7 - Posted 2007-03-17 20:10:32 »

You had to go and throw the gauntlet down didn't you ;p

Hmm, that ones proving to be a little trickier Smiley. Looking in the debugger in eclipse it appears as though the profile data manager etc are already installed, so it's not as simple as changing the property that sets the implementations of those. Hmm, the MasterTaskConsumer has an attribute of ProfileCollector that isn't set, so I think I need to look at that Smiley, I'm also waiting for something to open on port 43005 as listed in the AggregateProfileOpListener Smiley

Endolf goes to check what the licence said about decompiling the code Wink

edit
No need, Kernel contains com.sun.sgs.impl.kernel.Kernel.profile.level, time to find out what values it takes and what it does Smiley

Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #8 - Posted 2007-03-17 22:12:32 »

Your going to regret having thrown down the gauntlet Smiley

I figured through trial and error that the property goes in the sgs-config.properties, and that it's valid values are on or off (anything else gives you a warning message), when it's on I get 2 extra ports being listened to, 43005 and 43007, I made a wild guess and pointed a browser at the ports Smiley

TaskCounts:
  TotalTasks=205  AvgLength=108.70731707317073ms
  Transactional=89   AvgLength=249.6067415730337
  Successful=205  AvgLength=108.70731707317073ms  AvgStartDelay=14.575609756097561ms  AvgRetries=1.0
  AvgOpCountOnSuccess=108.14634146341463  AvgOpCountOnFailure=0.0
OpCounts:
   createReference=206/206   getBinding=254/254   setBinding=8/8
   removeBinding=2/2   nextBoundName=2/2   removeObject=1/1
   markForUpdate=2621/2621   createObject=210/210   getObject=16022/16022
   getObjectForUpdate=1/1   setObject=2841/2841   scheduleTask=0/0
   scheduleDelayedTask=0/0   schedulePeriodicTask=1/1   scheduleNonDurableTask=1/1
   scheduleNonDurableTaskDelayed=0/0   scheduleNonDurableTaskPrioritized=0/0


Second port gives

Snapshot[period=10000ms]:
  Threads=4  Tasks=6/6
  AverageQueueSize=0.16666666666666666 tasks


I've done the leg work to get it turned on, I'll let others figure out what it all means, although anyone who understands how to use the server API should be able to make some educated guesses Smiley

QED ;p

Endolf

Offline Hoyle

Senior Newbie





« Reply #9 - Posted 2007-03-18 18:52:16 »

Jeff,

I've created my own custom authenticator by deriving from IdentityAuthenticator.  I had a security question, when the NamePasswordCredentials object gets passed to the server, is the transmission of that password encrypted in any way?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline floersh

Senior Newbie





« Reply #10 - Posted 2007-03-19 00:27:38 »

Jeff,

I've created my own custom authenticator by deriving from IdentityAuthenticator.  I had a security question, when the NamePasswordCredentials object gets passed to the server, is the transmission of that password encrypted in any way?

No there is no encryption. It is sent in clear text across the wire.

I was attempting to write a challenge/auth system kinda like S/Key or Digest Auth in HTTP.. Seems that to accomplish that not only would I have to write a custom Authenticator but also a replacement for SimpleClient as simple client has no means to pass the challenge to the client.

Why they got rid of the JAAS Callback approach is beyond me. I guess they wanted it to be simple for 90% of the users.
Offline Hoyle

Senior Newbie





« Reply #11 - Posted 2007-03-19 02:31:28 »

Well even if they don't provide a secure transport for passwords, I don't see that it would be much of an issue of writing my own.  One simple way of doing it would be to simply allow the client to connect to the server under all circumstances, then after the connection is established build your own authentication protocol after the fact.

Offline floersh

Senior Newbie





« Reply #12 - Posted 2007-03-19 02:54:39 »

Well even if they don't provide a secure transport for passwords, I don't see that it would be much of an issue of writing my own.  One simple way of doing it would be to simply allow the client to connect to the server under all circumstances, then after the connection is established build your own authentication protocol after the fact.



Yep! Of course if all you wanted to do was encrypt the data you could do that with an Authenticator Impl. On the client you would simply need to encrypt the password before setting it on the PasswordAuthentication object.. Of course you would have to encode the encrypted password as a series of characters.. (aka Base64 or something like that)..

Or they could simply return to the JAAS Callback methodology and make the Container useful and extensible? (Aka if we are going to write everything ourselves where do we want to stop?)
Offline Hoyle

Senior Newbie





« Reply #13 - Posted 2007-03-19 02:58:06 »

I litterally started looking at Darkstar yesterday, what is the JAAS Callback methodology?
Offline floersh

Senior Newbie





« Reply #14 - Posted 2007-03-19 03:16:43 »

I litterally started looking at Darkstar yesterday, what is the JAAS Callback methodology?

Lots of things changed since the last public release. In the previous release they had a TCP<SomethingOrOther> client. When the connection was established with the server the server would iterate a list of Validators (kinda like JAAS Login Modules). Each Validator had the ability to send a collection of Callback handlers from the server over the wire to the client. Each time this occured a handleAuth(Callback[] callbacks) method was called on the ClientListener.

Aka the JAAS Callback methodology. In this case I could implement a Callback called Challenge which included a random string and a numeric. Thus when I got the password from the user I could hash it with the random string numeric number of times before setting it on the PasswordCallback. And all of that could be returned to the server and parsed without concern of the type of transport.

In the current release they have simplified (over simplified in my estimation) the communications stack with this SimpleClient. Now rather than the server challenging the client at all the protocol (aka SimpleClient) defines a getPasswordAuthentication() and it calls it and sends it to the server during connection irrespective of whether or not the server even cares. Obviously PasswordAuthentication only accepts username/password. So it is impossible to implement any sort of SmartCard, DigitalCert, DigestAuth, or any type of Auth mechanism other than username/password. Likewise, since it is part of the protocol (hardcoded) rather than an abstract pattern you must replace the SimpleClient with a REAL client to do anything different.

But the biggest hassel of this methodology is that you MUST implement some sort of userid/password even if the server doesn't even care? Aka if you plan on using NullAuthenticator which is the default by the way on the current release..

To me it makes more sense to impl the JAAS Callback methodology in a generic fashion and then have them provide a simple and null implementation for those 90% of users but provide the other 10% with the ability to quickly implement something stronger without having to write our own client/server transport and or apply layering to our application as you suggested.

By the way there may be an issue with your idea of implementing the auth system after connection. When the connection occurs the ClientSession is created by the server.. (aka out of your control). To construct this object it needs a name. That name is the userid of the user. What happens when the server has two ClientSession objects with the same USERID (aka Name)?? I'm not sure but I doubt it could be good. And without authenticating prior to creating this object you open up a potential security vulnerability.
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #15 - Posted 2007-03-19 07:40:44 »

Duplicate user id's are easy to detect, and you just have to return null from the AppListener loggedIn method, I already do that.

Being the Sun Game Server I suspect that they figured that most of us would be using username/password type authentication, and anyone using anything more complicated was in the minority, but could do it be extending simple client and the authentication implementation in the server. IIRC Jeff has said the docs to cover the stack extension are due out the same time the stack goes open source, which is due for Java One.

What is currently shipping is a restricted distribution binary, so you can't publish anything with it anyway yet, which makes security not an imediate concern. I'm sure somewhere down the line someone will wonder why the whole comms layer is not encrypted in some way, IIRC (no, I don't have any references, but its something I remember reading) a large number of modern games encrypt all the wire traffic anyway to stop people inspecting and manipulating the protocol. Again, I suspect that the stack can be extended to include this functionality.

Endolf

Offline floersh

Senior Newbie





« Reply #16 - Posted 2007-03-19 11:58:58 »

Duplicate user id's are easy to detect, and you just have to return null from the AppListener loggedIn method, I already do that.

Being the Sun Game Server I suspect that they figured that most of us would be using username/password type authentication, and anyone using anything more complicated was in the minority, but could do it be extending simple client and the authentication implementation in the server. IIRC Jeff has said the docs to cover the stack extension are due out the same time the stack goes open source, which is due for Java One.

What is currently shipping is a restricted distribution binary, so you can't publish anything with it anyway yet, which makes security not an imediate concern. I'm sure somewhere down the line someone will wonder why the whole comms layer is not encrypted in some way, IIRC (no, I don't have any references, but its something I remember reading) a large number of modern games encrypt all the wire traffic anyway to stop people inspecting and manipulating the protocol. Again, I suspect that the stack can be extended to include this functionality.

Endolf

I realize that they are playing the numbers game. But there is more. The concept of JAAS is very Java specific. They are also planning on an API that will work with various client languages such as C and I am sure others.. And JAAS Callbacks are inherintly Java most especially when you start talking about custom callbacks. I mean how would you send Callbacks in language neutral way? You would have to define the Callbacks as messages of some sort. Thus eliminating the ability to create custom ones.

And I realize that language nuetrality is a core objective and an important one. It would be possible to define the API to support it. Even if they had to have the Authenticator implementation do the encoding/decoding of the messages being transfered between the server and the client.. Aka how to encode/decode custom callbacks? Let the implementation do it!

And your right in the long run I am sure they will include support for SSL. Which could be an alternative.
Offline Jeff

JGO Coder




Got any cats?


« Reply #17 - Posted 2007-03-19 14:25:19 »

Duplicate user id's are easy to detect, and you just have to return null from the AppListener loggedIn method, I already do that.

Being the Sun Game Server I suspect that they figured that most of us would be using username/password type authentication, and anyone using anything more complicated was in the minority, but could do it be extending simple client and the authentication implementation in the server.

Pretty much. We figured for development the most you'd want is simple username/password.  For release we figured you'ld want to plug it into your own authentication and user management. system which would be custom and specific to each installation.

The EA stack actually used the JAAS mechanism and, honestly, we found it over-complicated the issue without a lot of benefit.  The "password" passed back to the system is actually a byte buffer and can contain any data your authenticator wants, including serialized JAAS callbacks if thats how you want to do things.

Quote
IIRC Jeff has said the docs to cover the stack extension are due out the same time the stack goes open source, which is due for Java One.

Yes indeedy.

Quote
What is currently shipping is a restricted distribution binary, so you can't publish anything with it anyway yet, which makes security not an imediate concern. I'm sure somewhere down the line someone will wonder why the whole comms layer is not encrypted in some way,

This is why the transport protocol is ALSO pluggable Cool
Games tend to all have their own, often hidden, schemes for packet security.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline sethp

Senior Newbie





« Reply #18 - Posted 2007-03-23 15:49:51 »


Hey folks. As the guy responsible for the profiling and authentication systems, I wanted to chime in with a few clarifications..

On Authentication: The discussion thus far has been pretty good. One thing to understand is that there is no assumption that name and password pairs is what must be used. This is an artifact of the initial Protocol being used, which only supports challenging clients for a name and passphrase. The Client API that is currently available is designed to work with this simple protocol. Likewise, the Authentication modules written thus far for the server support the protocol. When the code is released, you'll be able to plugin new protocol handling, which will also let you define any authentication scheme you wish. As folks have already discovered, the authentication system on the server is pluggable; if anyone has specific questions about how to use this, feel free to ping me.

On Security of Credentials: Related to how users are authenticated, and how credentials are expressed, is how the process is secured. The "easy" and standard way to protect this process is either to use TLS to protect the communications, or to use a one-time scheme; both of these have been discussed here already. Again, when you see how to plugin protocols, you'll also see how to support these schemes. Rest assured that the current model is designed with all of this in my mind. If you google for some of the security-related work I've done, you'll see that I have a passion for this stuff  Smiley

On Profiling: Yeah, those numbers are somewhat dense, huh? Here's the short version. We have a basic profiling system in the current stack that lets us monitor what's going on. Over the next several weeks we'll be adding a number of features, but currently you can observe stats about tasks, retries, queue-length, operations within a task, etc. There's also a generic listener interface for consuming these statistics and formatting them. The two that output on ports 43005 and 43007 are examples that we've been using to watch some basic aspects of the system internals. Again, if anyone wants more detail about these, feel free to ask. Pretty soon we'll be releasing all the details about how this works, and you'll be able to write your own modules to observe, aggregate, and correlate what's happening. On the whole, I think it's pretty cool how much data you can extract about the state of the system.

Hope this helps..


seth
Offline karmaGfa

Junior Member




Miaow


« Reply #19 - Posted 2007-03-24 10:04:32 »

Lots of things changed since the last public release. In the previous release they had a TCP<SomethingOrOther> client. When the connection was established with the server the server would iterate a list of Validators (kinda like JAAS Login Modules). Each Validator had the ability to send a collection of Callback handlers from the server over the wire to the client. Each time this occured a handleAuth(Callback[] callbacks) method was called on the ClientListener.

It sounds to me that you will be able to do this via jnag.
Just ignore the login and password, leave it empty, and accept the connection. Then, use jnag to do pass the callbacks from the server to the client and use it on the client to answer the challenges via the passed callbacks.

I will probably publish a new version of Jnag in a few days on CVS.

<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Offline Jeff

JGO Coder




Got any cats?


« Reply #20 - Posted 2007-03-24 16:34:13 »

Keep in mind that if you liked the old JAAS system there is no reason you couldn't write it as a  plug-in authenticator.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline floersh

Senior Newbie





« Reply #21 - Posted 2007-03-24 16:53:12 »

Keep in mind that if you liked the old JAAS system there is no reason you couldn't write it as a  plug-in authenticator.


One thing that might be worth asking is if the Idenitity object can be made available through the ClientSession. Currently it seems like it is little different from a Principal object. (aka nothing but a name).. It would be nice for Authenticator impls to attach Permissions or Credentials or some other properties on an implementation by implementation basis. Of course all of that would be worthless if the application couldn't get reference to them because they were shielded by the ClientSession object.

I would propose that the ClientSession API include a

public Identity getIdentity()

or

public Identity[] getIdentities();

method so that the Authenticator could implement any type of Identity it wanted and include any type of property with the Identity impl and finally the application could actually use them..

Of course you could leave the Identity interface opaque requiring application specific casting or it might look something like:

public String getName()
public PermissionCollection getPermissions()
public String getProperty(String key)

Anyway, just a thought..
Offline sethp

Senior Newbie





« Reply #22 - Posted 2007-03-25 03:19:39 »

One thing that might be worth asking is if the Idenitity object can be made available through the ClientSession.
[...]
I would propose that the ClientSession API include a [...] method so that the Authenticator could implement any type of Identity it wanted and include any type of property with the Identity impl and finally the application could actually use them.

Actually, there's something similar to what you're proposing in the current model. While an Application can't get access to the Identity object, a Manager can. So, what you can do is write a new Manager (and Service) that provides exactly the kind of methods that you're talking about. The Identity interface is opaque, and indeed authenticators do get to implement any type of Identity, and therefore include any type of properties that they like. The idea is that with these different Identity implementations you could expose different features through different Managers. I know that the Manager/Service extension API isn't clear right now, but (and I know this sounds familiar) when the code is published this will be clear. In fact, Jeff is working on a great guide to walk you through exactly this process.

In the meantime, folks should let me know if they want to prototype something like this now, and I'll get you started on the right path. Also, don't be surprised if we release some examples in the future that do exactly the kind of thing you're suggesting Smiley


seth
Offline floersh

Senior Newbie





« Reply #23 - Posted 2007-03-25 12:22:47 »

Actually, there's something similar to what you're proposing in the current model. While an Application can't get access to the Identity object, a Manager can.

seth

Thats good news.. Thanks..
Offline tigeba

Junior Member





« Reply #24 - Posted 2007-03-26 19:54:07 »

For those that just can't wait for the server extension docs to come out (that includes me), I put up a little tutorial on creating a custom authenticator that uses a database.

http://www.darkstarusers.com/tutorials/2007/03/26/creating-a-custom-identityauthenticator

I may have created an entire site dedicated to Project Darkstar in the process. Who knows.  I should have some more interesting stuff up in a few days.

Offline jeff_seattle

Junior Newbie





« Reply #25 - Posted 2007-03-27 00:16:32 »

I see that the client framework is setup for handling the PasswordAuthentication callback, but I don’t see anything on the server side for processing the provided credentials. Is this going to be forthcoming in the next release?
Reference SimpleClientListener::getPasswordAuthentication()
Offline Jeff

JGO Coder




Got any cats?


« Reply #26 - Posted 2007-03-27 01:01:54 »

But the biggest hassel of this methodology is that you MUST implement some sort of userid/password even if the server doesn't even care? Aka if you plan on using NullAuthenticator which is the default by the way on the current release..

Not sure i get this at all.

If your referring to the user/password callback in the current client API, you can respond with whatever you'ld like, including just an empty string if you arent using the password.  You could even put a block of serialized JAAS callbacks in there is thats your druthers.  At the moment though the protocol does not support the requesting of those JAAS callbacks.  If you wish to do that, you need to implement your own transport protocol, which is also pluggable.

"SimpleClient" is a front end designed for the simple name/password authenticators we have right now and the protocol they use.

We haven't exposed pluggability on that level  yet  on the client side because we are still figuring out the right way to do that, but it will be part and parcel with releasing pluggable transports.



Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #27 - Posted 2007-03-27 01:09:30 »

I see that the client framework is setup for handling the PasswordAuthentication callback, but I don’t see anything on the server side for processing the provided credentials. Is this going to be forthcoming in the next release?
Reference SimpleClientListener::getPasswordAuthentication()

This is handled by the authenticator right now.  We ship with two right now, a default NullAuthenticator and an encrypted file based password authenticator.

Custom authenticators are going to be fully documented  in the coming SGS Extension Manual to be released at Java One.  Til then you can get a peek at some info the community has figured out here:

http://www.darkstarusers.com/tutorials/2007/03/26/creating-a-custom-identityauthenticator

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline jeff_seattle

Junior Newbie





« Reply #28 - Posted 2007-03-29 00:50:14 »

If I wanted to pass more than just username and password from an SGS client to an SGS server during authentication, for example to include an Integer representing site_id, what would I need to do?  Huh
Offline tigeba

Junior Member





« Reply #29 - Posted 2007-03-29 02:53:01 »

If I wanted to pass more than just username and password from an SGS client to an SGS server during authentication, for example to include an Integer representing site_id, what would I need to do?  Huh

Without resorting to anything fancy, you could easily squirrel this information away in the username or password fields.  As you can see from the database auth example I posted. you can override the authenticator in the server side and you have complete control over what happens there.

Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (25 views)
2014-08-19 09:29:53

Tekkerue (24 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (13 views)
2014-08-16 06:20:21

Tekkerue (20 views)
2014-08-16 06:12:11

Rayexar (58 views)
2014-08-11 02:49:23

BurntPizza (38 views)
2014-08-09 21:09:32

BurntPizza (30 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!