Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Effectiveness</strong> (Will they do what they should do?)</p> <p>All of 1, 2, and 3 will work</p> <ol> <li><p>eval the responseText: This will work fine. If you add in a same-origin challenge per security recommendation #3, you must correct it first. </p></li> <li><p>Identify individual items in the object to "revive". I've used this approach before, and prefer to use a naming convention for the keys to determine when to revive, rather than a marker in the value. See <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse</a> for a description of revivers.</p> <p>In both cases 1 and 2, you will have to somehow cause the function text to be parsed &amp; executed. Here are your options. None is really less evil than the others (see section on security)</p> <p>If you use f=eval(responseText), this is a "direct eval". The function will have local scope where the eval is called.</p> <p>If you use f=(1,eval)(responseText), this is an "indirect eval". The function will have global scope. See <a href="http://perfectionkills.com/global-eval-what-are-the-options/" rel="nofollow">http://perfectionkills.com/global-eval-what-are-the-options/</a></p> <p>If you use f=new Function(responseText), the function will have a separate local scope under the global scope.</p></li> <li><p>This method is called JSONP (for JSON with padding). It will work and is probably the easiest to implement. It is also not good when the response may contain sensitive user data (see below).</p></li> </ol> <p><strong>Security</strong> (Will they not do what they should not do?)</p> <p><strong>IF the delivered message IS under your control (100% sure no user/attacker can modify it):</strong> All of options 1, 2, and 3 do NOT compromise the user's browser state (i.e. XSS, e.g. enabling things like stealing their cookies). </p> <p><strong>IF the delivered message IS NOT 100% certainly under your control:</strong> All of methods 1, 2, and 3 DO compromise the user's browser state and are unsafe. Your options are:</p> <ul> <li><p>Accept the security risk (users/attackers will be able to arbitrarily change your site functionality, including but not limited to: stealing your users' cookies for the domain, stealing any information the user has access to on your domain, directing your users to malware-infested pages to potentially install viruses)</p></li> <li><p>Pass the potentially unsafe functions into a webworker and run them there. They will be sandboxed and cannot affect the browser window. However, this is more work and not available in all browsers.</p></li> <li><p>Pass the potentially unsafe functions into an iframe on a separate domain and run them there. This protects your users' cookies,etc. but does not prevent attackers from redirecting them to exploit sites to install viruses (though you can just hope your users have secure browsers :-/ )</p></li> <li><p>Use whitelisted functions that you do control and just pass around the name of the whitelisted function (or factory functions that are essentially whitelisted functions with a few flexible parameters)</p></li> </ul> <p><strong>IF you pass user-specific information in your data:</strong></p> <ul> <li><p>3 is not safe for passing around sensitive user data (the script can easily be called with the user's cookies from any domain), unless your server implements checks on the referer/origin HTTP headers of the request before returning the response. Even then it can supposedly be unsafe. See <a href="http://en.wikipedia.org/wiki/Cross-site_request_forgery" rel="nofollow">http://en.wikipedia.org/wiki/Cross-site_request_forgery</a></p></li> <li><p>The <em>naive</em> implementations of options 1, 2 are also unsafe in this way (i.e. XSRF. e.g. a malicious site can forge a request for the data on behalf of the user using their cookies and then do what they like with it). A third party domain can overload the built-in Array constructor and then insert a script tag pointing to the JSON file. The browser will request this file with the user's cookies, return the user's JSON to the third-party site, and the javascript engine will "run" the JSON, which is just a single statement, but because the Array constructor has been overloaded, it can do whatever it wants with the data as javascript tries to construct the value in that single JSON "statement"</p></li> <li><p>For 1 and 2 to be XSRF safe, you should put a statement that would cause it to break if interpreted as a script, such as invalid syntax or an infinite loop, then your script should receive the text and modify it to remove the error. This is because same-domain scripts have access to read the responseText of a request before they parse it, whereas cross-domain scripts can only access this information by inserting a script tag with this as the source.</p></li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POParsing functions stored as strings in object literal/JSON syntax and differetiating
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USFabio Beltramini
    1. USFabio Beltramini
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POParsing functions stored as strings in object literal/JSON syntax and differetiating
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload