Closed r-a-y closed 9 years ago
Hm. How would we address it? During an AJAX request, the only way for BP to know what page you're "currently" on is by looking at the referer.
Hm. How would we address it?
Using a workaround to manually add the path or full URL using $_REQUEST['_wp_http_referer']
on BP calendar pages:
https://core.trac.wordpress.org/browser/trunk/src/wp-includes/functions.php?marks=1439-1440#L1426
If we rely on '_wp_http_referer', what are we protecting against? This
can be spoofed even more easily than the $_SERVER
variable. If we're
just protecting against the weird setup of your dev environment, then I
suppose we should do nothing :)
On 04/20/2015 10:15 PM, r-a-y wrote:
Hm. How would we address it?
Using a workaround to manually add the path or full URL using |$_REQUEST['_wp_http_referer']| on BP calendar pages: https://core.trac.wordpress.org/browser/trunk/src/wp-includes/functions.php?marks=1439-1440#L1426
— Reply to this email directly or view it on GitHub https://github.com/cuny-academic-commons/bp-event-organiser/issues/33#issuecomment-94614642.
We're not really protecting anything. It's just that non-related events could appear in a user calendar or a group calendar, but only when someone (like me) is messing around with referer browser addons :)
Just encountered this issue when testing on a browser that has the referer spoofed to use the root domain and no path.
This is mostly due to AJAX and
bp_core_set_uri_globals()
. Totally edge case.Not sure if we want to address this or not.