TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Bobby Tables

33 点作者 nikbackm超过 7 年前

19 条评论

red_admiral超过 7 年前
If I could downvote topics, this would get one.<p>We have an API for that. It&#x27;s called prepared statements.<p>We also have a lot of other APIs that try and do away with SQL, and fail in one of two ways. The first is people write code like personDAO.fetchAll().toList().size() - admittedly you can make the same mistake with SQL but I haven&#x27;t noticed this quite as much. The second way is that SQL is a very powerful language once you combine cursors, grouping, inline views etc. and I haven&#x27;t yet met an ORM libary that can come close. So you&#x27;re back to fetchAll() and do the work on the web server if you think SQL is a scary language that you don&#x27;t want to touch.
评论 #15841710 未加载
评论 #15839311 未加载
评论 #15839565 未加载
Areading314超过 7 年前
Is this a joke? I&#x27;ve never met someone who had a hard time with safe query parameterization.<p>It&#x27;s wrong to say sql can be replaced with &quot;an api&quot;, it does not have the same flexibility, power, performance, etc. And would drastically slow down your development. Also, what is &quot;the api&quot; going to use? Text files?<p>It&#x27;s better to teach people to practice safe SQL than to require abstinence.
评论 #15839036 未加载
评论 #15839031 未加载
评论 #15840279 未加载
评论 #15838937 未加载
评论 #15839798 未加载
paulddraper超过 7 年前
Proper SQL parameterization is a great example of where library&#x2F;language design has a lot to offer.<p>For example, in Java<p><pre><code> &#x2F;&#x2F; IMPROPER PreparedStatement statement = connection.prepareStatement( &quot;SELECT * FROM users where email = &#x27;&quot; + email + &#x27;&quot;&#x27; ); statement.execute(); </code></pre> vs<p><pre><code> &#x2F;&#x2F; PROPER PreparedStatement statement = connection.prepareStatement( &quot;SELECT * FROM users WHERE email = ?&quot; ); statement.setString(1, email); statement.execute(); </code></pre> The first code is easier and simpler than the second code -- especially if have lots of parameters, or if your queries start mixing arbitrary data and variable parts of the SQL. So people are sometimes going to write the first code.<p>---<p>In contrast, Scala has more sophisticated facilities than Java. I contribute to <a href="https:&#x2F;&#x2F;github.com&#x2F;lucidsoftware&#x2F;relate" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lucidsoftware&#x2F;relate</a> where the example would simply be<p><pre><code> &#x2F;&#x2F; GOOD sql&quot;SELECT * FROM users WHERE email = $email&quot;.asSeq[User]() </code></pre> It&#x27;s just so easy that no one is ever even _tempted_ to do the wrong thing. Use developers&#x27; laziness to your advantage, not your detriment :)<p>You can keep the full power of SQL (index hints, hand-tuned locking, DBMS-specific features), without constantly fighting the propensity towards SQL injection.
评论 #15839342 未加载
wrs超过 7 年前
This is a brilliant suggestion! We should also stop using HTML to prevent HTML injection, and stop using XML to prevent XML injection, and stop using the stack to prevent stack overflow.<p>(Actually, using an API <i>to build</i> SQL, HTML, and XML, instead of doing string substitution, is exactly the right way to prevent ___ injection, but that&#x27;s not quite what this says.)
BjoernKW超过 7 年前
&gt; What would replace SQL? An API of course!<p>Turtles all the way down. At some point you have to use some sort of data access language.<p>Providing an API instead of using SQL queries only works if you have a fairly limited number of different procedures to be called and data structures to be returned. Otherwise you&#x27;ll end up with a combinatorial explosion of API methods and input values.<p>If you view your SQL database as mere data storage that approach could be valid. If however, you&#x27;re working with complex relational models and data processing providing an API is a pointless endeavour.<p>I&#x27;ve seen (legitimate, mind you) SQL queries which were more than a hundred lines long and in turn called multiple additional embedded queries. Some of those queries used groups and window functions alongside with normal tabular data. Good luck with providing that as an API!
评论 #15839514 未加载
catnaroek超过 7 年前
I know of at least one language[0] that makes SQL injection impossible, by simply type-checking SQL alongside with the rest of your application, but I&#x27;m not sure Uncle Bob would like using it[1].<p>[0] <a href="http:&#x2F;&#x2F;impredicative.com&#x2F;ur&#x2F;" rel="nofollow">http:&#x2F;&#x2F;impredicative.com&#x2F;ur&#x2F;</a><p>[1] <a href="http:&#x2F;&#x2F;blog.cleancoder.com&#x2F;uncle-bob&#x2F;2017&#x2F;01&#x2F;11&#x2F;TheDarkPath.html" rel="nofollow">http:&#x2F;&#x2F;blog.cleancoder.com&#x2F;uncle-bob&#x2F;2017&#x2F;01&#x2F;11&#x2F;TheDarkPath....</a>
评论 #15839584 未加载
skywhopper超过 7 年前
This is a really poor article, that doesn&#x27;t give reasonable advice. SQL injection attacks are a big risk, for sure. But SQL persists because it&#x27;s incredibly useful. &quot;Stop using SQL&quot; is completely pointless advice.<p>Meanwhile, in the real world, every interface&#x2F;API&#x2F;protocol&#x2F;whatever has the potential for being exploited to do things that weren&#x27;t intended. You may as well say &quot;stop using computers!&quot;
whack超过 7 年前
<i>&quot;What would replace SQL? An API of course! And NOT an API that uses a textual language. Instead, an API that uses an appropriate set of data structures and function calls to access the necessary data.&quot;</i><p>Isn&#x27;t this similar to what frameworks and libraries such as Jooq do? They provide data structures and function calls where you pass in the user inputs, and the library will safely construct&#x2F;execute prepared statements. However, I still think of them as being SQL based tools. Is this what Bob is recommending, or does he have something completely different in mind?
mnm1超过 7 年前
&quot;And if you make absolutely certain that no text that crosses that boundary going towards the SQL engine has any SQL in it. Then you will absolutely prevent SQL attacks.&quot;<p>Not to mention your app will be extremely inflexible and likely slow beyond all hell. This is exactly what was done at my current work. The query overhead of the ORM system is 10x slower than the actual runtime of the query. 10 times slower. For overhead. Unnecessary overhead. For an engine that is completely inflexible, unusable, and increases development time by 2-10x (Doctrine 2 ORM if you&#x27;re curious). Really, this is the worst advice I&#x27;ve ever seen on HN. People have been creating such systems as the author describes for years and they have all failed in comparison to SQL. SQL prepared statements, on the other hand, are available to all languages and prevent injections. Other than specialized systems or DBs like Linq and Datomic, the only decent, solid relational database access systems I&#x27;ve ever seen in my life all relied on SQL.<p>I really can&#x27;t even imagine what the author is referring to at this point. Should I build out my own Linq or Datomic like layer for every app? Should I use an ORM with the right architecture that hopefully won&#x27;t slow my app 10x with its overhead? Should I just write a new DB from scratch? The article says to build an API. Well how is said API supposed to access the DB? Clearly, the author hasn&#x27;t thought this out at all.
评论 #15839374 未加载
cdevs超过 7 年前
Clean code and clean architecture are great books. I find sql injection from kids fresh out of college all the time in php but to be honest I really can&#x27;t tell the difference in that rails code. At work I&#x27;ve build a query helper function that takes a query string and a array of bindkeys&#x2F;bindvalues and everyone must use this, easy logging, easy security etc...<p>In this articles defense something SHOULD have been done instead of all the books that came out of their years that start off teaching sql injection and then barely mention injection near the end. It is a bit silly we still hear of this problem and the ongoing amazon s3 open links. The solution is typically some start up but the original software should have fixed its own problem, why did we end up treating database queries as low level and as powerful as letting users toss in assembly code.
评论 #15839582 未加载
RmDen超过 7 年前
is he trolling or what? You want an API.. it already exists.. Stored Procs, parameterized queries or ORMs which will use parameters........
评论 #15850370 未加载
meritt超过 7 年前
I was considering purchasing this author&#x27;s books (Clean Coder &amp; Clean Code) but after reading this unintelligible garbage, I&#x27;ll pass.
评论 #15839486 未加载
评论 #15850376 未加载
评论 #15838981 未加载
评论 #15838976 未加载
mangecoeur超过 7 年前
&gt; What would replace SQL? An API of course!<p>That literally describes all of &#x27;NoSQL&#x27;. Everyone is adding SQL back into their nosql systems, because it&#x27;s insanely useful. Since anyone remotely interested in databases knows this, I can only assume this is a kind of weird joke.
评论 #15840291 未加载
GuB-42超过 7 年前
Argument by ignorance.<p>The safe&#x2F;unsafe example is obvious to me, and I don&#x27;t even know Ruby. The unsafe cases have parameters, the others have not (they just build a string). And anyone who knows the basics of injection should know that building a string to be evaluated is naturally unsafe and should be done very cautiously.<p>The author makes it as some obstacle that is impossible to overcome, like you have to know some arcane symbols and magic. These things are basic operators. They are similar in most languages and any professional programmer should have a pretty good intuition on the matter.<p>Here is the reasoning :<p>User.where(&quot;email = &#x27;#{email}&#x27;&quot;) : unsafe &#x2F; the variable is between quotes, it should be a red flag<p>User.where(&quot;email = &#x27;%{email}&#x27;&quot; % { email: email }) : unsafe &#x2F; again, a quoted variable, bad. The &quot;%&quot; operator looks like a string manipulation operator rather than a argument.<p>User.where(email: email) : safe &#x2F; uhm... looks like a language idiom, need to look that up<p>User.where(&quot;email = ?&quot;, email) : safe &#x2F; a common way of doing prepared statements, seems OK. Unlike with the &quot;%&quot;, the &quot;,&quot; seems to imply that &quot;where&quot; is going to process the arguments, which is good.<p>User.where(&quot;email = :email&quot;, email: email) : safe &#x2F; another common way of prepared statements, again, the &quot;,&quot; implies several arguments.<p>What happen here is that too many people decide to switch off their brains. The &quot;unsafe&quot; forms are a relic, but some guy do it that way because it is how it used to be done, and some other guy copy because it &quot;works&quot;, then another, then another, etc... No one in the chain seems to question the practice, even though safer and more convenient forms exist. Having a new API won&#x27;t help, because if people are not even bothered to learn the safe way of doing SQL, there is no way they will use that API.<p>And sure, hiring inexperienced programmers, not giving them proper training, and making sure they can&#x27;t take the time to actually understand what they are doing doesn&#x27;t help...
perlgeek超过 7 年前
There are APIs around SQL that are pretty good in avoiding SQL injections; for example SQLAlchemy (a Python ORM) allows you watch pretty much any SQL query without writing literal SQL. You can use raw&#x2F;literal SQL, but it&#x27;s buried pretty deep in the docs.<p>Having a textual representation (with placeholders, of course) has some advantages I wouldn&#x27;t want to give up:<p>* learn once, use it everywhere<p>* it&#x27;s independent of the host language<p>* it&#x27;s a reification of a query or an action, which is very useful for logs (like slow query log), debugging and the likes
msangi超过 7 年前
Wait, I thought that Uncle Bob said that programmers should just be &#x27;professional&#x27; and stop being sloppy instead of reaching for tools that can help them<p><a href="http:&#x2F;&#x2F;blog.cleancoder.com&#x2F;uncle-bob&#x2F;2017&#x2F;10&#x2F;04&#x2F;CodeIsNotTheAnswer.html" rel="nofollow">http:&#x2F;&#x2F;blog.cleancoder.com&#x2F;uncle-bob&#x2F;2017&#x2F;10&#x2F;04&#x2F;CodeIsNotThe...</a>
obsession超过 7 年前
Now that we are on the topic of prepared statements, does anyone know how to do &quot;SELECT * FROM WHERE x IN (list of values...)&quot; properly? As far as I know, you cannot do it with prepared statements (as they can only be single values) and you are forced to roll your own escaping mechanism.
评论 #15840644 未加载
评论 #15840189 未加载
shapiro92超过 7 年前
There is only blame in this article. I kept scrolling bellow when he mentioned API, hoping for an elaborate answer. Nothing just complaining.
dctoedt超过 7 年前
Give the author (a bit of) credit for this much, though: His title seemingly alludes to <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;327&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;327&#x2F;</a> but he never mentions it, perhaps taking it granted that his readers will be familiar with it. Maybe the title was designed to attract attention; if so, it worked, at least with me.