|
Bruegels Fuckbooks posted:Php, mysql and w3 schools are all trash and javascript is a necessary evil. You want to pick up something about asp.net mvc .net core, something about typescript, and something about react. Node.js
|
#
?
Jul 5, 2018 13:32
|
|
|
|
| # ? Jun 7, 2024 17:54 |
|
|
Question about storing stuff an app needs that should be kept secret. Currently I keep the relatively small number of things my python / Django app needs to use that should not be public (tokens, secret keys, db info / passwords) in environment variables. This works well since they don't change frequently and additions are rare. However, that is going to change shortly. We work with a vendor who does SSO stuff for a lot of other organizations. So orgA, orgB, ... orgN all use vendorA for authentication, and we can log in users from all those orgs just fine by hitting vendorA's endpoint. To get user profile data beyond what the auth request gives, we need to hit a different API: one that will change for each org, and with a discreet auth token for each. So to get a user form orgA, we would have to request to orgA.vendorA.com and add Token: orgAsecretToken123 to the request. OrgB has their own url / token, etc. Given that there are 500+ organizations, and we will need to bring many online at once, manually adding environment vars every time seems like it will suck. Our database is an Amazon RDS that is encrypted at rest, and can only be accessed by our EC2 instance. Would storing these tokens in the database be an awful idea? If so, what is a sane way to store these things like this that need to be updated semi-frequently, preferably without having to restart the app to pick up said changes (if that is possible.)
|
|
#
?
Jul 5, 2018 16:07
|
|
|
baka kaba posted:Helpful Info This worked to handle what I needed. Thanks.
|
|
#
?
Jul 5, 2018 17:11
|
|
|
Lumpy posted:Given that there are 500+ organizations, and we will need to bring many online at once, manually adding environment vars every time seems like it will suck. Our database is an Amazon RDS that is encrypted at rest, and can only be accessed by our EC2 instance. Would storing these tokens in the database be an awful idea? If so, what is a sane way to store these things like this that need to be updated semi-frequently, preferably without having to restart the app to pick up said changes (if that is possible.) It's not awful, but depending on the level of damage a credential leak can lead to I might call it insufficient. Generally speaking, I try to not leave access tokens for anything in plaintext in my database. (As an example, when I create a session token and give it to a client, I store its hash rather than the token itself.) If all the keys are under 4096 bytes, I would suggest encrypting them via AWS KMS and a key that is IAM-provisioned to the EC2 instance running your application. (If the keys are not under 4096 bytes, generate an encryption key using something reasonably secure like Miscreant, encrypt the secrets, and encrypt that key with KMS). This way a database compromise does not leak all your users' credentials, but rather the EC2 principal must also be suborned. In your case it is an incremental improvement, because the likely way to pwn you is your application, but a lesser-skilled attacker is going to have more trouble unspooling the encrypted contents--which then can be decrypted only upon use--than just somebody doing SELECT * on your database. This is also effectively how Credstash and AWS Parameter Store work, should you need to do some more global secret protection down the line. tracecomplete fucked around with this message at 20:26 on Jul 5, 2018 |
|
#
?
Jul 5, 2018 20:24
|
|
|
carry on then posted:Node.js you don't need to read a book for that, you just need to hit yourself with one.
|
|
#
?
Jul 6, 2018 13:29
|
|
|
Node.js feels significantly better when you're in a polyglot environment with polyglot devs, and you can actually factor its strengths and weaknesses into your decisions. It's hard to beat for proof of concepts and lightweight transform pipelines where JSON is the input and output, especially if the latter is for personal use only and you don't need to worry about whether node will be installed on servers/dev workstations. That said, I'd be wary of working in a place where the servers are node.js, the clients are Electron, and JavaScript is the only way to get anything done. That type of work has always felt like a special circle of hell to me.
|
|
#
?
Jul 6, 2018 13:41
|
|
|
Bruegels Fuckbooks posted:Php, mysql and w3 schools are all trash and javascript is a necessary evil. You want to pick up something about asp.net mvc .net core, something about typescript, and something about react. Khorne fucked around with this message at 16:06 on Jul 6, 2018 |
|
#
?
Jul 6, 2018 14:49
|
|
|
What dues that have to do with node.js, though?
|
|
#
?
Jul 6, 2018 15:07
|
|
|
Thermopyle posted:What dues that have to do with node.js, though? You could connect to either with Node.js! Then again, have you heard the Good News of mongodb my friend?
|
|
#
?
Jul 7, 2018 02:00
|
|
|
Khorne posted:]MySQL is fine and no worse than PostgreSQL or any other popular SQL implementation. mysql is ok if someone else is developing the database - it's pretty stable once you get it to work. it's brain cancer if you actually have to develop for it, it literally exists to make oracle (which is the devil) look good.
|
|
#
?
Jul 9, 2018 13:38
|
|
|
Bruegels Fuckbooks posted:mysql is ok if someone else is developing the database - it's pretty stable once you get it to work. it's brain cancer if you actually have to develop for it, it literally exists to make oracle (which is the devil) look good. What exactly do you mean by developing for mysql? Modifying the implementation? Setting up a DB? Using the client? I assume you don't mean poo poo like writing queries.
|
|
#
?
Jul 9, 2018 16:42
|
|
|
TooMuchAbstraction posted:What exactly do you mean by developing for mysql? Modifying the implementation? Setting up a DB? Using the client? I assume you don't mean poo poo like writing queries. Mysql is really idiosyncratic out of the box (e.g stuff like https://codeascraft.com/2013/03/19/the-perils-of-sql_mode/). Historically it was missing a lot of features as well (e.g. It didn't handle nested sub-selects, didn't support data partitioning, didn't offer multiple transaction isolation levels, didn't support triggers or stored procedures.) Before innodb, it wasn't even acid compliant. Releases were pushed out with serious issues that caused data corruption (e.g. https://planet.mysql.com/entry/?id=16232). I've run into problems like building indexes crashing mysql, data types getting converted implicitly for weird reasons, and other weird poo poo. Like it might have gotten better in the past few years, but I've used ~seven different types of relational databases commercially, and I'd rank it as maybe second worst.
|
|
#
?
Jul 10, 2018 14:06
|
|
|
Bruegels Fuckbooks posted:didn't support triggers  one of my colleagues was griping the other day about how you have to be some kind of OS superuser to make a trigger and how bad that design is. I told him characterizing MySQL as 'designed' was being far too charitable.quote:I'd rank it as maybe second worst. OK hold on what's worse?!
|
|
#
?
Jul 10, 2018 16:01
|
|
|
Munkeymon posted:
MSAccess.
|
|
#
?
Jul 10, 2018 16:05
|
|
|
Bruegels Fuckbooks posted:MSAccess. Running over the ODBC-JDBC bridge.
|
|
#
?
Jul 10, 2018 16:09
|
|
|
Bruegels Fuckbooks posted:MSAccess. Ah, I don't tend to think of it as a database but I guess technically it is, yeah
|
|
#
?
Jul 10, 2018 17:05
|
|
|
And what is the best and is it IBM Informix?
|
|
#
?
Jul 10, 2018 17:30
|
|
|
lifg posted:And what is the best and is it IBM Informix? I was gonna guess that was the worst, except I forgot Access was a thing. Also, the place I used to work used to use MS ADAM as a database.
|
|
#
?
Jul 10, 2018 18:11
|
|
|
lifg posted:And what is the best and is it IBM Informix? Microsoft® SQL Server™ 2017
|
|
#
?
Jul 10, 2018 20:45
|
|
|
Bruegels Fuckbooks posted:Mysql is really idiosyncratic out of the box (e.g stuff like https://codeascraft.com/2013/03/19/the-perils-of-sql_mode/). Historically it was missing a lot of features as well (e.g. It didn't handle nested sub-selects, didn't support data partitioning, didn't offer multiple transaction isolation levels, didn't support triggers or stored procedures.) Before innodb, it wasn't even acid compliant. Releases were pushed out with serious issues that caused data corruption (e.g. https://planet.mysql.com/entry/?id=16232). I've run into problems like building indexes crashing mysql, data types getting converted implicitly for weird reasons, and other weird poo poo. Like it might have gotten better in the past few years, but I've used ~seven different types of relational databases commercially, and I'd rank it as maybe second worst. The only real "danger" of learning MySQL now is that you'll follow a really bad tutorial. Something like all of the MySQL tutorials pre-2008 were vulnerable to SQL injection or just did really dumb things. It seems like a large portion of people who uses databases, or any library really, just mash things together without taking the time to learn them or understand how they work. You'll also probably just find some tutorial that's pushing some ORM or bloated-magical-will-solve-that-you-are-a-bad-engineer-for-sure web framework rather than one that teaches you SQL itself while peppering in some MySQL specifics. Khorne fucked around with this message at 02:58 on Jul 11, 2018 |
|
#
?
Jul 11, 2018 02:25
|
|
|
Khorne posted:MySQL <= 5.6 silently truncates inserts under some conditions with its default settings. And most people who used MySQL didn't know or expect that. The people setting it up usually don't know that, and the people who programmed for and used it certainly didn't know it on a lot of the projects I've worked on. Yeah, but you know, you could start by picking a tool that sucks less and has fewer pitfalls to begin with. Like, I don't really know why this is, when people spend a lot of time learning a product, they get stockholm syndrome, start justifying the bad behavior. It's partially caused by how people are educated in that they are conditioned to think that learning something is its own reward. Yeah, I could use mysql now, and even get it to work - but I would prefer to use database products that have not already wasted months of my life in the future. And gently caress this attitude of "oh, it's in the documentation - like for instance, with RabbitMQ, they decided to change the configuration file format from JSON to key value pairs, but the product comes with example config files in the old format (that don't work with the new format.) MongoDB mentioned in the documentation that on 32-bit OS, once your database reaches 2gb, it will silently fail and start stop storing new data without throwing any exceptions or logging any problems! I mean yeah, technically, both those things were totally mentioned in the documentation, but just documenting something that's a gently caress you doesn't mean it isn't still a gently caress you.
|
|
#
?
Jul 11, 2018 14:55
|
|
|
Yes but have you considered that it's the cheapest RDBMS option on AWS?!
|
|
#
?
Jul 11, 2018 15:08
|
|
|
Munkeymon posted:Yes but have you considered that it's the cheapest RDBMS option on AWS?! Not only that, but MySQL is easy to get started with. At the end of the day 99.999% of the applications out there that use MySQL never hit those problems. Because they will never have that much amount of data. For them, LAMP was the best thing since slice bread. Sure, it is an awful stack, awful language, awful database, but hey, they did their thing, it worked (at least in demo), got their paycheck and went happily on their way. 10 years later they call you, the expert, to come and unfuck their poo poo since now they got a ton of records and the DB keeps missing data and the reports take 1 day to generate. But that's fine, since the peanuts they paid for that simple CRUD app was more than worth it and it probably save/made their company millions of $.
|
|
#
?
Jul 11, 2018 16:45
|
|
|
Is MySQL easier to get started with than Postgres?
|
|
#
?
Jul 11, 2018 18:14
|
|
|
Thermopyle posted:Is MySQL easier to get started with than Postgres? Yes when the only tutorial you've read only mentions MySQL. Odds are you don't even know PostgreSQL even exists. Maybe heard of Oracle, but that's it.
|
|
#
?
Jul 11, 2018 19:10
|
|
|
You need better tutorials e: or newer ones
|
|
#
?
Jul 11, 2018 19:11
|
|
|
Thermopyle posted:Is MySQL easier to get started with than Postgres? Switching from one to the other is painless if all you are doing is learning. He was asking what to learn initially, and the answer is your experience will be about the same with either. MySQL is used more in industry because innodb has some tangible performance benefits over postgres' engine in some real common use cases. Nerds love postgreSQL because it's more compliant, has more features, it's stricter and won't let you do bad things as much, and all that kinda stuff. For most people and businesses, just pick one. For most uses, their performance and feature sets are practically identical. Khorne fucked around with this message at 19:50 on Jul 11, 2018 |
|
#
?
Jul 11, 2018 19:11
|
|
|
The Fool posted:You need better tutorials We're talking here about the new graduate or that accountant that happens to know a bit of programming and that whipped together that little app for their company. We're talking about done on the cheap. Hell, you're lucky that they actually read a tutorial and didn't just dive in applying hearsay knowledge they had. "Better tutorials" only applies to someone given the time and who has the interest to learn more. Usually is a miracle that whatever they make actually works.
|
|
#
?
Jul 11, 2018 21:05
|
|
|
What about MariaDB?
|
|
#
?
Jul 12, 2018 00:16
|
|
|
Just pick a random one from here IMO.
|
|
#
?
Jul 12, 2018 00:25
|
|
|
Star War Sex Parrot posted:Just pick a random one from here IMO.
|
|
#
?
Jul 12, 2018 00:30
|
|
|
peepsalot posted:Where's the I'm Feeling Lucky button? Star War Sex Parrot fucked around with this message at 00:54 on Jul 12, 2018 |
|
#
?
Jul 12, 2018 00:31
|
|
|
Star War Sex Parrot posted:Just pick a random one from here IMO. I won't use BuntDB because they're missing an "l".
|
|
#
?
Jul 12, 2018 01:12
|
|
|
Star War Sex Parrot posted:Just pick a random one from here IMO. Looks like a perfect opportunity to create a "real or not" game a la this.
|
|
#
?
Jul 12, 2018 01:22
|
|
|
Khorne posted:MySQL is used more in industry because innodb has some tangible performance benefits over postgres' engine in some real common use cases. Nerds love postgreSQL because it's more compliant, has more features, it's stricter and won't let you do bad things as much, and all that kinda stuff. For most people and businesses, just pick one. For most uses, their performance and feature sets are practically identical. Good post but also leaves out a key reason nerds don't like MySQL - Oracle tries their hardest to turn everything they touch into poo poo.
|
|
#
?
Jul 12, 2018 01:24
|
|
|
Khorne posted:MySQL is used more in industry because innodb has some tangible performance benefits over postgres' engine in some real common use cases. This may or may not be true, I do not know. But, I do know industry and organizations and I'm willing to bet institutional inertia is just as much to blame as is someone sitting down and doing a detailed comparison and saying "you know what, for our use case, innodb has some important advantages".
|
|
#
?
Jul 12, 2018 01:38
|
|
|
redleader posted:Looks like a perfect opportunity to create a "real or not" game a la this.
|
|
#
?
Jul 12, 2018 01:43
|
|
|
MySQL's popularity has a lot to do with the LAMP stack, and that's popular at least a little bit cause it has a memorable acronym.
|
|
#
?
Jul 12, 2018 01:54
|
|
|
Thermopyle posted:But, I do know industry and organizations and I'm willing to bet institutional inertia is just as much to blame as is someone sitting down and doing a detailed comparison and saying "you know what, for our use case, innodb has some important advantages". On this subject - are there any good books/blog posts/whatever on the subject of inertia and affecting change, preferably with a focus on software development? It's honestly the most challenging thing in my career at this point.
|
|
#
?
Jul 12, 2018 02:34
|
|
|
|
| # ? Jun 7, 2024 17:54 |
|
|
Khorne posted:MySQL is used more in industry because innodb has some tangible performance benefits over postgres' engine in some real common use cases. Does it maintain those advantages if you either turn off global dirty reads on MySQL or enable them on Postgress?
|
|
#
?
Jul 12, 2018 13:33
|
|