-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for transport plugins #183
Conversation
@frekw This is awesome! I'm going to want to look at this over the weekend then I'll give my feedback. 👍 |
Any news on this patch? I was just about to hack raven so I could proxy requests to our sentry server and it looks like a simple modification of the default transport plugin here would serve me well. |
Don't want to complain but I need this patch. |
Is this likely to be dropping anytime soon? |
+1 |
Anything we can do to keep this moving? |
@gmathieu Test it out. :) |
return HTTPGetTransport; | ||
} | ||
|
||
if(!dsn.pass) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd recommend also checking if the user wants https here so they could also use http+post
if(!dsn.pass && dsn.protocol == 'https+post')
I'm gonna hack on this tonight fwiw. |
|
||
;(function(window, Raven, undefined){ | ||
'use strict'; | ||
var V8Transport = window.V8Transport = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not call this one XHRTransport?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because sadly, this doesn't just work everywhere that XHR is accepted, so this is specific to V8.
As this is coming up more and more, I think we're going to need to push this through. One point of feedback I'd like to make: it's probably worthwhile to drop our DSN "https+foo" notation in JavaScript. I think from a usability standpoint its great, but in JavaScript where minifiers are still king its wasteful (as it cant be optimized out). What if instead we did this:
Again, ideally here the minifiers have enough information to optimize out the unused code (transports) and then we could bake in both (CORs and Legacy) by default for our distributed JS bundle. (I'm open to alternatives here, I just want to make sure the systems can optimize out unused code, and we still maintain it well enough to use both the current transport as well as the new cors stuff) |
Here's what I propose, built on this existing PR:
|
@dcramer What advantage would a jQuery transport bring over plain XHR? |
@realityking just less code. It may not be relevant, but I imagine the XHR transport having an excess of duplicated code. |
@dcramer I may be a bit slow right now (it's late...) but wouldn't any code size benefit require, that the XHR transport isn't bundled by default either? |
@realityking thats correct. The goal is to optimize around the patterns that are becoming more common: requiring modules vs some offline bundler (require.js, common.js, webpack). In that case we could default the transport but allow them to swap it out, which should allow deduplication tools to remove the module. |
@dcramer Gotcha, I had forgotten your comment from 2 days ago. Thank's the explanation :) |
We would really like to see support for custom transport. We are using a proxy to pass these requests through to Sentry and don't want to support the DSN scheme in our proxy. |
What's the security risk - if any - of putting the |
@ksikka the secret removes the referrer check entirely, thus making it a very easy abuse vector |
@dcramer can we fix this by changing the sentry API logic to allow SSL AJAX POST requests without a secret but with an origin/referrer check? |
@ksikka I'm not sure what you mean. All public key requests already look for the origin/referer (no matter the scheme). You can use '*' as the allowed domain and it will bypass the actual match. |
@dcramer When the method is POST, we're in this I'm asking, should we change the API code so that if it's an SSL AJAX POST, the API does not require |
@ksikka ah! yeah we would definitely need to fix that upstream |
@dcramer @mattrobenolt Any updates on this? |
@numaanashraf – I think this patch is still in limbo and will likely end up closed. In the meantime, if you need to override the default request creator, you can do so by specifying a https://github.com/getsentry/raven-js/blob/master/src/raven.js#L748 |
Also, to clarify, this is undocumented for a reason right now. 😉 This is likely the approach we're going, but we're not committing to it just yet. |
Documentation for the |
I'm closing this now in favor of our approach that made it into 1.2.0. Thanks everybody. :) |
This patch introduces support for registering additional transport plugins, thus making it possible to override how Raven pushes data into Sentry.
New transports are added using
Raven.registerTransport(protocol, handler).
wherehandler
is an object implementing the signature{ setup: function(dsn, triggerEvent), send: function(data, endpoint) }
.What transport is used is figured out by parsing the DSN passed into
Raven.config
.This patch also introduces a
V8Transport
which uses CORS to push data into Raven via XHR.Further discussion can be found here: #157