Quote from: adriweb on August 14, 2013, 05:56:11 pm

- the key would only be for the app store software, so just one key, not for its users.

Then it's a public key, it can't protect you from anything.

Well, running a strings command on the executable would reveal it, probably (depending on how it's hardcoded, though), but 0.01% of the people would try that - and I'm not sure to see why they would do it if they can get their own by "asking".... It's certainly not the best protection but at least it's not nothing, and would stop 90% of novice "hackers"-wannabe. But anyway, without a secure connection, a wireshark sniffing could reveal the data sent... like any program using an api with a key, when not over an encrypted connection

Quote

- I'm not sure a cache would be such a great ID as the request can vary quite enormously, and the cache would get quite huge (?)

It would make sense for requests heavy for the database, search as full-text search (these one are actually not so random) or app listing (a few hundred kb, not so big but I/O intensive for a database).

Well, we'll have to see after some usages what the most often requested things are, and plan accordingly ?

(mods: feel free to merge if judging as double post, meh)

I have integrated the &gz=1 (default 0) flag, but I don't really know how to test - at least it gives me no error, either on the client side not the server side :

https://github.com/TI-Planet/API/commit/6dc9c20b761753d08104a9a14173fbbae9e22eaa

Delete that useless header( stuff. It will only confuse file_get_contents on the other side, me, and my browser, which wants to download a file api-response-something.gz  Just output it directly. BTW: gzencode is PHP > 4.0.4, but gzdecode is PHP > 5.4 -.-

I'll be looking at http auth (but there may be some underlying issues with apache/lighttpd that I don't really control / know about
Lionel ?)

Just a .htaccess with auth user file and requre valid-user. In the PHP file you can get the user with $_SERVER[PHP_AUTH_USER].
Or make the authentication optional, then serching should only be allowed if the user is authenticated.

Ok, for the header; do I just leave one for the charset or something ?
And... what about encode/decode, do I need to do something else?

For our RPC the output is simply the following: echo gzencode(json_encode($result));Our RPC client uses:
$remote = @file_get_contents("http://" . self::$username . ":" . self::$password . "@" . self::$host . "(...)", false, $context);
        if($remote === FALSE) (...)
        $result = json_decode(gzdecode($remote), true);


And for the .htaccess that's exactly the problem, we don't use them our tiplanet as they don't work (don't ask me why) - last time we tried to understand, we couldn't see...

Grep the whole apache config directory for "AllowOverride", most likely that's your issue.

btw, for us lighttpd is for http and apache for https.

May I ask why?

it's normal to show me this if I've ndless r825?

Yes, it's too old.

the 825?:s as I know it's the newest...

EDIT: nevermind, I didn't saw the r848

No, 877. By request of compu a new feature got added which pacspire uses.

the 848 is the newest as I can see

http://www.unsads.com/projects/nsptools/downloader/download/release/1
The last one says 877.

but if you see the first...says 848

But the last one is 877.
877 > 848!

:O I was thinking that i was writting/seeing 884 -.-
I think that I need a rest xD