Almost all webapps we write, we write them this way. (on oracle, not postgres, but that makes no difference).
> your application needs to be designed for it from the very beginning.
That's true. As in "you can not add security later on".
2,612 karma · joined May 15, 2008
Almost all webapps we write, we write them this way. (on oracle, not postgres, but that makes no difference).
> your application needs to be designed for it from the very beginning.
That's true. As in "you can not add security later on".
Well... no. If you lock down your db correctly, using the correct privileges for the users accessing the data, and using veil or rls, the sql executed on the db is just an other way of accessing the data you can see anyway through the webapp. The webapp becomes just a nice frontend so the user does not need to execute sql directly, and if there is an sql injection vulnerability the attacker would still be able to only see the data he has the right to see anyway. He is just accessing it with sql instead of the webapp.
I still love it. Thanks for the module.
You can use your own dns server. Just install a recursive dns server on your own network like https://www.powerdns.com/recursor.html or https://unbound.net/
That is just a quick fix for 0.6.1.
0.6.2 was released about 2 hours after 0.6.1.
I actually like it. Write once, run everywhere has become true. Of course there is always room for improvement, but that too is happening (and with a really fast peace too).
- direct access to printer: the user wanted to print on a specific tray of the printer, without selecting it every time. JS only implements window.print() with no fine grained printer control.
- serial/parallel/usb access: access to a POS for card processing, and we needed to write some data on a smartcard.
- plain TCP connections
- read/write files on the local filesystem.
I understand that all these features require more control of the underlying hardware and need to be somehow secured, but we did not want to write a desktop app just for these features, and applets gave us the means to implement what the user needed. Once JS can do that, applets can die a quick dead.
- Are they used for different things on the sites?
- Is data partitioned across tables?
- Are they all SQL Server instances?
Cache: http://webcache.googleusercontent.com/search?q=cache:https:/...
That is not much info :)
Just for reference: a simple query by pk index on my veryveryvery low end pc¹ on a table with 1mil rows takes about 0.04 ms (so says pgsql analyze). That is 25000 queries per second. What type of app are we talking here where the db needs to scale? Something like reddit? Stackoverflow? Just curious. Never saw such a beast where a DB server needs that much power. Where I work we have 200 apps on the same DB server, and it's idling most of the time.
¹i5 CPU 2.40GHz with 2GB of RAM
> run Python scripts as stored procs. Great way to slow down your DB.
There is more than one way to shoot yourself in the foot :)
I never understood this argument. Maybe you can elaborate a bit? Almost all our apps use sp for data lifting work (most of the so called "business logic"), and we never got scaling problems. Well, we don't have that much users or data either, but how many users/data do you have that your stored procs could not keep up with? What numbers are we talking about?
What makes the db slow is throwing bad sql at it, not Stored Procs.
Well, we have to migrate about 6000 pcs, and it's a 1 and ½ years project. Much more than six moths.
Well then, TACK changes "the protocol". As you know better than me it proposes changes to the TLS handshake and how CAs are verified.
Nobody, not in the article and not in the post you replied to, sad that the protocol needs to be replaced. In fact, both say the exact opposite.
I like your posts, and you clearly know what you are talking about, but this time it seems you don't discuss the article, but just hop in the discussion with random and not correlated, but true facts.
The author made the example of the movie database and explained why it was a good idea when they started, and why it didn't work out. Can you point out an example of data you would store in a document database, which is not purely for caching purposes?
A disable cache checkbox in the developer tools options.
Who cares? The article writes about Android. Just because iOS i even less free does not make Android better.
No, the change went live Friday: https://bugzilla.mozilla.org/show_bug.cgi?id=914690#c20
It's already live. ff24 is the current stable.
It's completely different. You don't need to remember an url, you don't need to remember a password, there is no third party involved in the authentication process, ... I could go on, but it's really a completely different authentication mechanism.
no. the same message does "never" encrypt to the same cypher:
$ echo lol | gpg -e -r F8669BB7 --armor
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11 (GNU/Linux)
hQEMA2gTLr1USDZGAQf/YbbnzHvNfdqbs6hmdmIaaiZOSfW9P6Bc8tdF4MG/JbP+
RTxbLpi4W+vXs+WrD9jdik8KuDdZV54O1mb6Ido3xrYeEPBo0Vje2eVpgUy01VUa
2RM76NvsX1VN9rap6KvHuO/h7IFwDuAtvUUcDyFH+qK2UEHordFi+mWKqICocQt0
WWgpCk5BVgM/1q2c2ruWxVuZs/IMh9LQGZ1i7hpkJHAYqovhghROmGarUuJYXGDi
s6rSMpjxbXDhPMYbbhbBI4pRhgKtN2FMlKyI3XoH+LCFHsOyBmazroVYWFu+gafH
6LU2Z65OQyJWqX5CLdwab4qpUQdht6lqkUHRJB9xdtI/AfTFF7BbRP8PR+q9GVAe
r4I812VmBn3hwBHJzNiFDEGVkt/IDpd6M/X2Vi0xJx0LUaICL+swPVudenPuvlnt
=zeUd
-----END PGP MESSAGE-----
$ echo lol | gpg -e -r F8669BB7 --armor
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11 (GNU/Linux)
hQEMA2gTLr1USDZGAQgAo4ZEHGWKSgwVmbC7crACvTXVtlgP4n8J/3oSohct9zrM
SqPd4L5TWsjOh+2LlG7WQbPnpn4Tcv9c4RyPNb+1C/fWRmGhV+a3QhuC+rrus5c6
/FPwsHTjO30N0AnCMzoXAaqDRRGw859BKazEZyxIHherU+o7wNRKrW6U1ikRd/Pu
BwHChUZHBRmZhomrtYPbQ5cNAJQtPMj94Z8OuZeCEzPNBr3opevoMs2j+9ysOtkF
7Cam3jTKLM3GwHSm4c7WzhdJJsXbnOn8ODYRBf++4oJChPIqeT2EssigAQuuhHlk
pDhM40zB7hAd6MJM52cZpM3UqTe/iI4vHSrQ+pw/otI/AWY6s4aIlF5AAzoM0wAR
FzobJ5Vbp7fBgA1SiOhEhSAdT/U2yy2jQcQN53yyX9Vqtunh3dNmCGaNNavszK8+
=YDLc
-----END PGP MESSAGE-----
$Just don't load third party js from a domain you don't own, use tls and you are good.