Sorry guys for not having done that option yet, but I'm a bit worried where all this will end, so we've come up with another solution, but we're still checking the details involved. When we're done with that I'll explain it here.
IMPORTANT if you're making use of the pubstats, read the following :
NEW : Login
---------------------
The option to login has been introduced. For now this will be voluntary, but pretty near in the future it will become obligatory for logging purposes, so you best start using this option right now.
Your login (the same as your LFS account) can be passed onto the pubstats via the following two url-variables :
&user=<username>
&pass=<password>
<password> may be your password in plain text, or you can md5 it before sending (strongly recommended).
Victor is there any possibility of a set of "magic keys"? i.e. rather than LFS username and password, a key system similar to which google uses, which all transactions must provide? I'm a little wary of LFS account information being passed around...?
<stupid><question>Why?</question></stupid> I can see it might be useful for tracking who is using how much of what, but beyond that I don't see a great deal of point. Unless that is going to become the basis of a new tarpit / fair usage system?
I want to remove the tarpitting for those who _really_ want to be able to use the pubstats without restrictions. But there still has to be some mechanism to prevent people from abusing this possibility and I want to do that with a pay-system.
You can eat out of our fridge all you want, but leave some cash behind so that we can stock it again. In reality that means that the funds will go towards expanding the servers in the future when it's needed.
This way you can get all the stats you want if you really want to, and at the same time contribute to making sure things can keep running in the far future. Additionally I don't think a pay system is very weird, because in the end you're using our resources for your own purposes.
The free pubstats will remain just as they are. You don't have to pay if you don't want to. But those who want to have the tarpitting removed can have it removed for a small fee, based on usage. I'm in the process of determining the fee - it'll be low - how low I don't know yet.
ohyeah, that does mean that I won't be doing the latest request for multiple racers in one go. Those who want bulk-stats can opt to have the tarpitting removed.
Ah, good idea! Most sites related to LFS that might want to use this are community resources, and as such are usually privately funded, but as long as it is reasonable I think it makes sense to charge for this as an additional / premium service. However, given that the login data passed on the url now has extra value, I think I'd be way more comfortable in either someway of seeing stats for the data requests made with my login data (so I can see requests made using a pinched login), or having a token (like google maps dev keys) that is tied to my server. The later would be preffered. The login data could be accidentally exposed a million and one ways, some of which are preventable, others less so.
there will be a page later on that will show monthly logs for everyone using pubstats.
And about the login info - I think I'll make a 'generate login-key' field or so, that will give you a unique code for identification purposes.
Dunno if that accidentally is the same as those magic keys?
Presumably you mean that each user needs to login to LFSworld, and hit the "generate me a pubstats key kthnxplz" button. This key you then use as your unique ID to query pubstats? Or are you thinking some kind of public and private key system?
I'm all for either to be honest Just as long as logon details arent directly involved, and you can regenerate the keys as often as needed
I've done most of the background work - now have to start thinking about the UI. Then there also has to be additional payment methods, so you can 'upload credits' to your account (like a pre-paid service). So all in all this will still take a couple of days up to a week or so. Also this prepaid idea will probably be used for other future services as well (but I won't be jumping ahead of myself here ) so it needs to be thought through well. In other words, I'm working on it, but several things will be changing so it will take a bit.
That isn't far off the google maps 'magic key' idea. The only difference being is that the google maps API keys are generated from an URL. Any requests made from any other URL using that key just don't work.
Since you can't really rely on the referrer field using http requests (google have the advantage of their system being JS based, and can check the current location directly), may I suggest that multiple keys can be assigned to an account, and each key is tied to the server IP address. That still isn't 100% secure as people on vhost packages sharing a server would be able to use each others key if they got a hold of it, but it certainly does narrow the field down a bit.
Of course, you'd also want to generate it on username and/or password, and maybe have a bit of random junk thrown in there just to give anyone trying to create keys themselves (if they got hold of username / password & IP) a hard time.
I'm pretty sure most developers should be clued up enough to be able to figure out their servers IP address.
P.S Multiple keys might be required, because for instance my development server and hosting server are separate machines, but I'd like to be able to use both at the same time.
*edit* Unrelated note; with JS disabled all of my new lines get stripped, but enabled it's ok?!? Whats that about? */edit*
I'm making a test *desktop* application with the barely working version of libLFSW. Do we really want a desktop user to have to work out their IP? Doubly so they're going to get pissed if they need to work it out everytime they connect to the intarweb (i.e. dynamic IPs). I'm fairly sure this might be a good idea for websites and such, but not other uses...
A special case "development key"? One that isn't tied to the IP. If I'm paying for this key, I want some assurance that if some gimp pinches it they aren't going to get far with it.
Perhaps, but at the end of the day I want to release this for everyone, and I dont particularly want to use my own key, rather whatever one the user has..or doesnt have.
Sorry if you've covered this already. I've made a ircbot which give feedback when a pb, wr or hotlap is requested by a trigger. Will this type of usage be covered by a fee, or will such information be available for free?
if your bot already runs and it runs without problem, then I'd say, just leave it like it is.
If however, you want every request to be realtime for example, then you could choose to go for the premium option, so that you won't be bothered by tarpitting anymore.
To summarize;
*the current free tarpitted system remains - nothing changes, apart from that you'll have to add identification with every request so I know who makes a request. I'll let everyone know about the refined identification options later on.
*The pay system is just for those who want to have the tarpitting removed (the forced 5 seconds interval).
I am a bit confused at encoding the right LFS join path...
I wanted to use this like in the quote above:
<?php function urlhost($hostname){ if (stristr($_SERVER['HTTP_USER_AGENT'], 'MSIE')){ // IE $hostname = preg_replace ("'\+'", "%252B", $hostname); return $hostname; }else{ // Any other browser $hostname = urlencode ($hostname); return $hostname; } } ?>
But in IE with a host that have a "|" like "T7R|Public 1" in the name, make the game won't start at all.
In Firefox 1.5 the game can't find the right host. A simple hostname like "OLD MEN RACING Public" gets encoded like "OLD+MEN+RACING+Public" which is also what I see in the game's Join Specific Game screen. But it gives a "Host not found on master server" message.
Edit:
As a matter of fact, all join links on LFSWorld give the same "Host not found on master server" message with Firefox. Or is that just me?
I think only the host names with a space in it don't work properly. For example 1ST|Racing works fine (both IE and FF), though 1ST|Racing - FOX only works in IE, with this code:
) so it needs to be thought through well. In other words, I'm working on it, but several things will be changing so it will take a bit.
(p.s. sorry we're such fussy buggers)