I probably won't have that done today since I'm leaving for a short trip today (gotta enjoy the sun, the weather's actually smiling at us here in Sweden for a change) but I'll add that to my TODO-list, thanks!SomeGuy99 said:
And the bug that I've now reported twice? :unsure:craigix said:
dflemstr said:
As was mentioned, exposing your database to end users is ultimately a bad idea. Even if it's just a "read only" user, you're exposing a great deal of risk.milkshake said:anyone fancy making any comments on my original suggestions?
WizardStan said:
8 is fine. The bug seems to be my filenanme is 12 (13 if you include the .). A more graceful death would be for it to do this check before it accepts the file for download and rejects it immediately instead of waiting 15 minutes for a file to upload that isn't going to go anywherecraigix said:
You could do what I did: I create a 16-letter random file name for each file, and use that to actually store it (take a look at some random app in my repo to see what I mean). Then, when the user wants to download the file, I use a "Content-Disposition" header to give it the name it was uploaded with. That way I don't get overwrite attacks in my file system, users can't do file name hacks to do cross-site scripting, and they can't "claim" file URLs that have a specific property (like being short etc). All URLs are equalcraigix said:
dflemstr said:
Could you try typing in "javascript:maybeLoadMore();" in your URL bar and see whether that loads more applications? It'd help greatly to know whether that changed anything. Thanks!graupelschauer said:
WizardStan said:As was mentioned, exposing your database to end users is ultimately a bad idea. Even if it's just a "read only" user, you're exposing a great deal of risk.milkshake said:anyone fancy making any comments on my original suggestions?
Give me read only access to a single table and I can write you an SQL that will lock that table indefinitely, preventing anyone else from reading or writing to it, possibly slowing down the entire server while it chugs along through this one SQL statement. That's the real danger. More exotic dangers are that, even if you only give someone read only access, there's no guarantee they won't find some crack to give them full access; and simply knowing the structure of the database (because you've previously given them read only) can give a hacker enough knowledge of how to bypass other security features (such as login and paid for downloads). Security through obscurity*.
*should not be your only form of security, but every layer helps.
SQL as a language is also unsuitable for an application API. And the bandwidth required to communicate with a SQL database is considerable. Also, there's still the issue of implementation: if the app store wants to change the way it stores applications internally, without changing the repository API, how would that be done?milkshake said:
dflemstr said:
Well, yes, and in fact, I've already done it (did it a week ago or so): http://dflemstr.dyndns.org:8088/repository.jsonmilkshake said:
i knew it could be done because thats how i would have done it.
. Perl was once awesome, now cranky but certainly it isnot a mistake to use, especially if Craig knows it. Don't be preposterous to dictate someone else terms or suggest evey perl app is bad
dflemstr said:
