<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Field-Level on Ian&#39;s (not so) technical blog</title>
    <link>https://dev-www.0x69616e.com/tags/field-level/</link>
    <description>Recent content in Field-Level on Ian&#39;s (not so) technical blog</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <copyright>Ian Wilson.</copyright>
    <lastBuildDate>Sat, 09 Nov 2024 00:45:24 -0600</lastBuildDate>
    <atom:link href="https://dev-www.0x69616e.com/tags/field-level/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Field Level Security (in rails) &#34;Done Right&#34;</title>
      <link>https://dev-www.0x69616e.com/posts/data-security-done-right/</link>
      <pubDate>Sat, 09 Nov 2024 00:45:24 -0600</pubDate>
      <guid>https://dev-www.0x69616e.com/posts/data-security-done-right/</guid>
      <description>&lt;p&gt;I&amp;rsquo;m a huge proponent of believing that security shouldn&amp;rsquo;t be something that&amp;rsquo;s baked in after the fact &amp;ndash; it&amp;rsquo;s something that should be all or nothing from day one. I realize that this is probably a wild and opinionated point of view, but, let me try to explain:&lt;/p&gt;&#xA;&lt;p&gt;When your application starts out, user account security is usually one of the things that you think of last unless you&amp;rsquo;re utilizing a framework that has some type of tenant segregation in from day one. While security is usually brought into the product at some point after the core functionality of the MVP is introduced, this is the point in the development lifecycle that can really make or break your application: make the right choice: a library that is well maintained, well documented, and well-tested, and hope that it not only has the support of the community, but, pray that it doesn&amp;rsquo;t commercialize itself later down the road breaking your core functionality&amp;hellip;or, roll your own. Rolling your own means ensuring that you&amp;rsquo;ve got a well-built set of definitions and goals for your authorization stack and that you&amp;rsquo;ve thought of everything your application needs from day one. Realizing that it&amp;rsquo;s a step in futility, most good engineers will try to add some things to your application to allow it to &amp;lsquo;future-proof&amp;rsquo; the application, basically locking himself to be the &amp;lsquo;forever authz guy&amp;rsquo; or worse, detrimental to your engineering team when that engineer leaves and all of that domain knowledge of the library or gem leaves after everyone on his team has left. (Oddly specific because I&amp;rsquo;ve lived through it. Twice). How do you solve for that? In my mind, that&amp;rsquo;s getting as close to the data as you can, and building forward from there. That&amp;rsquo;s where Soter comes in. Soter&amp;rsquo;s opinionated, secure by default, and easy to implement. Soter works on the belief that all data should be graded from the moment where it&amp;rsquo;s defined in the Model &amp;ndash; if the model hasn&amp;rsquo;t been graded, then the data is unavailable to display to the user. Grading the data is mandatory, but, granting access is optional. You could have fields that could only be available to the application, prohibited by rules in being returned as a JSON or other object, keeping those fields secure by default.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
