I have a very simple bit of code on a website
jQuery("#slist").load("sg-custom-code/SG-ajaxGetPastProds.php",{pd: jQuery(this).val()});
The path 'sg-custom-code' is off the root of the site. However the (Joomla) site uses SEO-friendly urls so it appends the apparent url of the page root (derived from the menu path) and tries to go to https://xxx.co.uk/everything-else/players/past-productions/sg-custom-code/.... and of course fails. The actual url should obviously be https://xxx.co.uk/sg-custom-code....
I can fix it by writing
jQuery("#slist").load("https://xxx.co.uk/sg-custom-code/SG-ajaxGetPastProds.php",{pd: jQuery(this).val()});
... but if a user then uses www.xxx.co.uk instead of xxx.co.uk it will fail with a CORS error!
Any ideas for how to work around this?
Related
I have a certification and a badge provided by Acclaim. I want to embed it in my personal website but it's not working. here's the code they provided:
<div data-iframe-width="150" data-iframe-height="270" data-share-badge-id="60615e70-6409-4752-9d77-3553a43d13d2" data-share-badge-host="https://www.youracclaim.com"></div>
<script type="text/javascript" async src="//cdn.youracclaim.com/assets/utilities/embed.js"></script>
but even when simply put onto an empty html:5 page, I get the error: Loading failed for the <script> with source “file:///assets/utilities/embed.js”.
What's the problem here? I'm not sure how Acclaim can provide a ready-to-paste script that's just simply not working, nothing shows up on the website. I'm guessing the problem is at the src... part, but don't know how to fix it.
If you're loading your page via file:, then protocol-relative URLs aren't going to work. The script tag has:
src="//cdn.youracclaim.com/assets/utilities/embed.js"
This should be changed to:
src="https://cdn.youracclaim.com/assets/utilities/embed.js"
You'll find though that when you're using an actual web server, this is a non-issue. The reason for the protocol-relative URLs is so that HTTP pages would use the HTTP version, and HTTPS would use the HTTPS version. This method is outdated anyway. HTTPS should be used everywhere, even if you're loading HTTPS JavaScript from an HTTP page.
I'm currently working on a project to track products from several websites. I use a python scraper to retrieve all the URLs related to the listed products, and later, regularly check if these URLs are still active.
To do so I use the Python requests module, run a get request and look at the response's status code. Usually I get 200, 301, 302 or 404 as expected, except in the following case:
http://www.sephora.fr/Parfum/Parfum-Femme/Totem-Orange-Eau-de-Toilette/P2232006
This product has been removed and while opening the link (sorry it's in French), I am briefly shown a placeholder page saying the product is not available anymore and then redirected to the home page (www.sephora.fr).
Oddly, Python still returns a 200 status code and so do various redirect tracers such as wheregoes.com or redirectdetective.com. The worst part is that the response URL still is the original, so I can't even trace it that way.
When analyzing with Chrome DevTools and preserving the logs, I see that at some point the page is reloaded. However I'm unable to find out where.
I'm guessing this is done client-side via Javascript, but I'm not quite sure how. Furthermore, I'd really need to be able to detect this change from within Python.
As a reference, here's a link to a working product:
http://www.sephora.fr/Parfum/Parfum-Femme/Kenzo-Jeu-d-Amour-Eau-de-Parfum/P1894014
Any leads?
Thank you !
Ludwig
The page has a meta tag, that redirects the page to the root URL:
<meta http-equiv="refresh" content="0; URL=/" />
I am working on a Greasemonkey script to turn some text into links on a a Rally page. The script works fine only when I reload the page. If I navigate to the page in any manner (links, browser forward/back) the script does not run, despite the fact that the Greasemonkey menu shows my script at the bottom, with a checkmark.
Here is an example URL:
https://rally1.rallydev.com/#/4745909548/detail/userstory/6138899084/changesets
My matching rule:
/^https://.*\.rallydev\.com/.*/changesets$/
I don't know if the hash is causing a problem, but everything is fine when I reload.
Not sure where to go from here. Any help is appreciated.
It's impossible to be sure what's going on, because the target page(s) are behind a pay-wall and their alleged "Free Trial" mechanism blows chunks.
Here are some possible causes of the current behavior:
The initial request is insecure (http) but redirects to a secure page (https).
The first page load does a some other kind of redirect to the actual page.
The target content is in an <iframe> that does not load right away.
The target content is AJAXed-in.
Something exotic that we would need to see the actual page to figure out.
The initial URL does not really end in changesets.
Also, get into the habit of escaping the /s in the middle of regular expressions. It's not always needed, but it will eventually bite you in the [censored] if you don't.
So the script should use:
// #include /^https:\/\/.*\.rallydev\.com\/.*\/changesets$/
to start, but see below.
Steps to a solution:
Change your #include to account for http and the Possibility of trailing space or trailing slash in the URL. Use:
// #include /^https?:\/\/.*\.rallydev\.com\/.*\/changesets(?:\s|\/)*$/
Examine the page with Firebug. Is the content AJAXed-in? Is it in an <iframe>? If so, what is the iframe URL, if any?
To also detect AJAX and/or redirects, use Firebug's Net panel and/or Wireshark.
If possible, provide us with login credentials so that we may see a problematic page.
Snapshot a problematic page (Save it via Firefox) and link to that HTML and JS in Pastebin.com.
Consider using code like:
if (window.top != window.self) {
//--- Don't run on/in frames or iframes.
return;
}
To have the script run only in (or not in) iframes, as applicable.
If the problem is caused by AJAX delays (or loading of new content), get around that by using the waitForKeyElements() utility as shown in "Fire Greasemonkey script on AJAX request".
I've built a site that uses the History.js plugin to navigate from page to page with AJAX and update the URL accordingly. All works well except in IE; when you refresh the page it essentially loads the content from the first page you came to, not the current pages content. In "decent" browsers it doesn't load the content from any page, it just loads the entire page for that URL, which is what I IE should do.
I'm thinking it doesn't understand what to do with the hash. If you visit
for example
example.com/something
it works fine, but when you visit example.com/#something (with the hash) it comes.
I've attempted to redirect the page if it detects a # in the pathname, but there is no way of detecting this as window.location.pathname and History.getHash() returns the path without any hash.
Any suggestions? I've seen a few websites using this plugin that have the same problem, and similar issues on here, but no solution.
Thanks in advance!
window.location.hash
should return the hash in your console.log (caveat - if you're testing for IE8, you should be able to grab the hash with the above, but you'll have trouble reading the object sin
My app at http://beta.billboard.fm is producing errors in my normal browsing session after playing a single song.
If i reload the page in incognito, the app works fully. I only recently starting experiencing these issues. I have completed cleared all of the cache and it works again, but only temporarily before throwing the same errors.
Additionally I have disable all browser extensions.
But, no matter what I do I can't get this error from being thrown by the Youtube API:
Unable to post message to http://www.youtube.com. Recipient has origin https://www.youtube.com
It looks like there is a mismatch in the security protocols. I tried changing them to https or just removing "http:" all together on my side. But it did not resolve the issue.
Any one have an idea what is happening here?
It is quite clear to me at this point that this is a major bug in Google/YouTube's API. They have written some bad code somewhere. This bug is not a consistent thing. This is well documented by the fact that everybody's code works just fine for an extended period of time, and then they discover that all of a sudden their sites stop working properly. Additionally, all of my websites that had this problem last week are now working without a glitch - again, without me altering code.
So while it sucks to say this - the onus is on Google & YouTube to fix this and provide APIs that actually work as advertised... It doesn't look to me like there's anything we can do about it on our own :(
I am having the same problem - I also tried changing my links to http: to https: and vice-versa with no luck. I found this tread on Google Groups, but so far there has been no response. https://code.google.com/p/gdata-issues/issues/detail?id=4697
Clearing my cache allowed the player to work for a few videos, but after 3 or 4, the same error pops back up.
UPDATE 2 - Dec. 24, 2013: This solution has not actually fixed the problem at all:
After following a thread that poulified referred me to in his answer, a user in the forum posted the following solution which seems to be doing the trick for me (UPDATE: Still experiencing issues on random page loads :/):
Hi all,
It is working for replacing http:// with https://
example: http://jsfiddle.net/8tkgW/29/
Please make sure the following tips
load iframe api https://www.youtube.com/player_api
load iframe src path: https://www.youtube.com/embed/0GN2kpBoFs4?rel=0
If load player via new YT.Player, you must check the iframe src path:
setTimeout(function(){
var url = $('#iframe_youtube').prop('src');
if (url.match('^http://') {
$('#iframe_youtube').prop('src', url.replace(/^http:\/\//i, 'https://'));
}
}, 500);
Please refer my github project:
https://github.com/appleboy/js-video-player/blob/master/js/jsplayer.js#L120