jonathan schatz

to the best of my knowledge it should work fine - what issues are you running into?

the `meta_request` gem stores traces locally keyed off of the `request-id` (see [here](https://github.com/dejan/rails_panel/blob/3dea94ee9eb5baa7af030a162579f8c06d785faa/meta_request/lib/meta_request/middlewares/app_request_handler.rb)). when the `rails_panel` chrome extension sees a `x-meta-request-version` header in a response it constructs a request to...

1. You are correct, by default there's no access-control at all. an attacker would have to guess a uuid to find a valid trace so at least there's some security...

i see, an attacker could set that. i think the solution there is to support something like `rack-mini-profiler`'s `Rack::MiniProfiler.authorize_request` i'm going to update the docs and add a warning in...

@gogiel i can get this gem released once it's merged, just ping me.

thanks @perrin4869 - this is a good idea but i'd like to keep things similar to the non-register case, and i'm not clear on the best way forward. one option...

adding my updates from the forum post: 1. if i build an `au` instead of an `auv3` then the result _does_ pass `auvaltool` 2. i found a report of almost...

> But since we've already brought it up, instead of changing from `link_to` to `button_to` and instead of adding the `:delete` data-tag, you might try editing your `config/devise.rb` to sign...

just came to report this, see also: https://github.com/relay-tools/react-relay-network-modern/issues/95 i'm working on a pr locally as well.

i think this might be a generally good option for all subscriptions, i'd guess other services would offer a batch api. i'm going to take a look when i get...