search

Woopra / node-woopra

nodejs library for Woopra
MIT License
4 stars 4 forks source link

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin #2

Open danjaviacm opened 8 years ago

danjaviacm commented 8 years ago 
XMLHttpRequest cannot load https://www.woopra.com/track/identify?ip=0.0.0.0&app=node&website=site.com&cv_uj=uj40&cv_channel=SEM&cv_email=user-1457100254154-45&. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:5000' is therefore not allowed access.

Can you help me please?

I use node sdk and reactjs

philosoralphter commented 8 years ago

Your app is binding to localhost but that is not acceptable to the server's access control policy for the response. This is a pretty common problem with testing web service in development. Try binding to 127.0.0.1 instead.

The request still will not work, though, as site.com is not registered in Woopra.

danjaviacm commented 8 years ago

Thanks! I will to revise it

On Mar 7 2016, at 5:44 pm, Ralph Samuel <notifications@github.com> wrote:

Your app is binding to localhost but that is not acceptable to the server's access control policy for the response. This is a pretty common problem with testing web service in development. Try binding to 127.0.0.1 instead.

The request still will not work, though, as site.com is not registered in Woopra.

—
Reply to this email directly or view it on GitHub.

jamesjjk commented 7 years ago

Hi my origin is Origin:http://127.0.0.1:3000 However still getting a cors issue. Any advice?

Kmaschta commented 7 years ago

Idem, I have the same issue

philosoralphter commented 7 years ago

Hi @jamesjjk and @Kmaschta--

So it looks to me like you guys are using browserify or the like to package this code for use on the frontend. Unfortunately, this library is not designed to work for that use case. We are considering updating it or creating a separate npm-installable package from our client side javascript sdk, but for now, unfortunately, you will need to use the javascript sdk to utilize our client side api.

The docs for that code are here: https://www.woopra.com/docs/setup/javascript-tracking/. You can use our snippet to install it on the page at load time, or you can find and package the script code yourself. Then that API will be available on the browser.

Let me know if this is an incorrect assumption, or if you have any questions! --Ralph

jamesjjk commented 7 years ago

Hi,

I have actually forked your library and made some changes to be able to use it isomorphically.. (server/client side renders). There are errors in the library btw. the cookie attribute is set as part of visitor as a conditional, it should be part of the client object.

James

On Thu, Sep 15, 2016 at 2:15 AM, Ralph Samuel notifications@github.com wrote:

Hi @jamesjjk https://github.com/jamesjjk and @Kmaschta--

So it looks to me like you guys are using browserify or the like to package this code for use on the frontend. Unfortunately, this library is not designed to work for that use case. We are considering updating it or creating a separate npm-installable package from our client side javascript sdk, but for now, unfortunately, you will need to use the javascript sdk to utilize our client side api.

The docs for that code are here: https://www.woopra.com/docs/ setup/javascript-tracking/. You can use our snippet to install it on the page at load time, or you can find and package the script code yourself. Then that API will be available on the browser.

Let me know if this is an incorrect assumption, or if you have any questions! --Ralph

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Woopra/node-woopra/issues/2#issuecomment-247195589, or mute the thread https://github.com/notifications/unsubscribe-auth/AM3I39CHDirpLdJaEqrWKXljizIPjnclks5qqI4cgaJpZM4Hq0lg .

Kmaschta commented 7 years ago

Thank for the response. You're right, I've used the Woopra JS library and it works well.

But what about an NPM installation for frontend or cordova integration?

philosoralphter commented 7 years ago

@Kmaschta: that's on the roadmap, but not very high priority. Maybe take a look at @jamesjjk's fork but note the below: @jamesjjk: The cookie sent as part of the visitor is used by the woopra system as a privacy-safe (that is, moderately ephemeral) "device id" in order to follow anonymous users. That is why it is on the visitor object.

jamesjjk commented 7 years ago

@philosoralphter that is great, but unfortunately conflicts with your documentation. It states it should be set on the client which seems to be correct even your JS library does this. I forked and updated the node library for this reason, by setting the cookie on the visitor its prepended with cv_ and its not identifying as a unique device but as another custom property. But hey just pointing it out, don't shoot the messenger.. https://www.woopra.com/docs/developer/http-tracking-api/

philosoralphter commented 7 years ago

@jamesjjk: Ah I see what you are saying. You look to be correct on that. My apologies! Would you like to submit a PR with just that change?

I don't want to take your other change of not setting a default client ip to 0.0.0.0, because that would mean that if you don't put the client's ip there, our servers will use your server's ip to match with the session and make assumptions about location, company, etc. With 0.0.0.0 we avoid those automations in the case that a node sdk user forgets or does not forward client ips.

Sound good?

EDITED: PS: Is it simply that default client ip change that allowed you to use the library on the client side? If so then at least that issue can be solved by ensuring users set the client ip using the client() method. I could put this in the docs to help users like @kmaschta above...

jamesjjk commented 7 years ago

@philosoralphter Yep its a simple as not setting the client ip that would allow both client side use and isomorphic rendering. Maybe we could add another conditional to check if the user has set an IP, if there is no window object or so.. But ultimately it may be better to leave it blank. And simply add to doc. Let me know what you would like to do?

philosoralphter commented 7 years ago

Thanks @jamesjjk. I will consider, and let you know.

philosoralphter commented 7 years ago

@jamesjjk: could you help me out a little. I am in the midst of another project and do not have time to test this fully myself. I did not write this code, I am just maintaining it now, and I have never used browserify, and don't typically work on the front end. I have a few questions that maybe you could clear up for me.

First, why do you think that changing the _defaultClient.ip is affecting your CORS outcome? It looks to me like that value is simply set in the url query parameters for our servers to use--it does not set the client ip on the request, and is not used at the protocol level at all. It's just a piece of data in the query and should not affect CORS.

Second, did you say that your woopra account is not receiving the events when you get these CORS errors? Even if your browser refused to load the resource, our servers should still take the tracking data. Unless a pre-flight request was sent, but I believe this does not happen as it is a GET request with no custom headers. Let me know if I am wrong about this.

Perhaps you could share the error from your console, and maybe let me know your woopra project too so I can take a look at your data?

Thanks for your help with this.

jamesjjk commented 7 years ago

@philosoralphter

btw. Woopra is pretty awesome so far, I have only just started testing it but its looking good. Looking forward to implementing it on our production platform.

philosoralphter commented 7 years ago

@jamesjjk Awesome! I'm glad you're liking woopra. Sorry about some rough edges in this repo, it's actually very lightly used and so does not receive much TLC.

So how about you send a PR with the cookie/visitor bug fix (commit 3a7a287357f1a923383a2723b6e2df8e37d9317c) And reserve the other change with the ip parameter out of that PR, and I will look into that in the near future when I have a little more time to test fully and see how we can handle all of this best.

If you don't care, I can just make that change too btw. instead of a Pull Request.

jamesjjk commented 7 years ago

@philosoralphter Hi just in case you guys are interested I updated node woopra with clients side support (commonjs) using a jsonp library for compatibility with your server. Good for all those isomorphic react projects: https://github.com/jamesjjk/node-woopra

evanwchurchill commented 7 years ago

@jamesjjk I'd be interested in using your fork, as our project has run into some expected cases with our tracking events being a bit off because of how react works. Is there any major change in how to implement it from the base repo? Currently I'm having to fire a custom track even on the app container's componentDidUpdate method, so that document.title has been populated at the time the track event fires, but doing so I lose out on some of the information that the generated code from Woopra provides, when put in the static index.html, such as duration.

Love both the NPM module and Woopra, though! Really useful tools.

philosoralphter commented 7 years ago

@jamesjjk and @evanwchurchill : I just pushed a couple small changes that you should rebase onto. (git pull --rebase upstream master)

They are some docs, a version upgrade for npm convenience, and the ability to send referers (and clearly documenting sending timestamps!!)

Let me know if you have any questions. Also, let's talk about how your branch, james, has been working in production, etc. and I will put it on my //todos to think about merging it in. (please rebase to pull in new changes first.) And @evanwchurchill let's discuss your issues with react. I have heard of others too, and want to see what we can do about making it work more easily with react.