gt; error could have unintended consequences in security/data leakage,
>> serialization, or memory/GC. If this path were chosen, an array of result
>> ID's might be a safer choice.
>>
>> -Al
>>
> On Tue, Jun 21, 2016 at 3:17 PM, John Mileham <jmil...@gmail.com>
In order to make use of the additional information in the exception, as a
developer, you'd be delving into exception based control flow (i.e.
rescuing the exception and performing conditional logic on the payload).
Rails admittedly does this for a couple things (like catching
RecordNotFound
to me that json:api endpoints are a higher-level contract than rails
controllers would be expected to provide out of the box.
-john
On Thu, Feb 26, 2015 at 12:40 PM, John Mileham jmile...@gmail.com wrote:
To me it sounds like there are three points of view here:
WW: Developers should never wrap
To me it sounds like there are three points of view here:
WW: Developers should never wrap params, dirty root is fine, prefer to
deprecate the wrap_parameters feature (rebutted by DHH below)
DHH: Wrap parameters is useful to normalize between the common JSON style
of not using a root and the
What about the security ramifications of logging potentially sensitive
information? IDs can be sensitive, but often far less than other fields.
There are legitimate use cases for using find_by on values that you'd
prefer not to be logged or known by the end user. Making
more-informative error
I feel like there definitely would be some security risk but I can't think
of a real, solid example. Can you lay one out for me?
Hi Michael, here's one example. Let's say that you must be the creator of
a project to add issues to it (perhaps contrived in this case, but many
access control
On Tue, Jun 5, 2012 at 10:09 AM, Matt Jones al2o...@gmail.com wrote:
On Jun 5, 2012, at 8:18 AM, John Mileham wrote:
It's easy to dismiss as an obvious mistake, but I've seen it done too
many times to want to encourage deeply nested routes by automating the URL
generation. If your
One reason that the code to generate all those URLs seems not to be DRY
might be that any URL that can be programmatically deduced from the model
at the end of the chain is itself non-DRY. i.e.
/users/1/projects/2/issues/3 adds no more information than /issues/3 would
in that case. Obviously in
MySQL is the only database I'm aware of for which `select 'Bla' = 'bla';`
returns true. So while it looks odd from a MySQL user's perspective to
perform LOWER on both sides, it's the correct way to do case insensitive
matching on a SQL92 database. Also, on databases like PostgreSQL and Oracle
at
opinion is just to not use it and write your
own :uniqueness validator for
string column types.
-- Panayotis
On Oct 17, 6:56 pm, John Mileham jmile...@gmail.com wrote:
MySQL is the only database I'm aware of for which `select 'Bla' = 'bla';`
returns true. So while it looks odd from a MySQL
Has anyone run into a similar issue?
Hi Sidu,
I ran into this as well and submitted a pull request:
https://github.com/rails/rails/pull/2678
The patch brings ActiveResource in line with HTTP 1.1 when determining
whether to read the body of a response. The dependency on
Content-Length was
11 matches
Mail list logo
