Hello SoundCloud Team :)
When embedding SoundCloud items into WordPress via the SoundCloud Shortcode plugin, the iframe's src is set to w.soundcloud.com/player?url=.... Apparently, the correct URL is w.soundcloud.com/player/?url=... (with a trailing slash).
When the page is served over HTTPS, the iframe's non-trailing-slashed src's scheme is correctly set to https. However, the non-traling-slashed https URL is redirected to a trailing-slashed http URL, which causes a mixed-content error and prevents the embed from loading.
$ curl -IL 'https://w.soundcloud.com/player?url=https%3A//api.soundcloud.com/tracks/142702630&auto_play=false&hide_related=false&visual=true'
HTTP/1.1 301 Moved Permanently
Location: http://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/142702630&auto_play=false&hide_related=false&visual=true
...
HTTP/1.1 302 Found
Location: https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/142702630&auto_play=false&hide_related=false&visual=true
...
HTTP/1.1 200 OK
...
One (or both) of the following would solve the issue.
Change the redirect to go to an https URL.
Update the plugin to point to the correct URL.
I dug around a bit and had found effectively the same answer on:
https://wordpress.org/support/topic/shortcode-does-not-work-with-website-ssl
I can say that if you are having an issue with SoundCloud on WordPress over SSL, add the '/' character as recommended and the problem simply goes away. That is, alter the URL in the soundcloud_iframe_widget() function to add '/' prior to the trailing '?' in
// Build URL
$url = 'https://w.soundcloud.com/player/?' . http_build_query($options['params']);
in the file
$WORDPRESS_HOME/wp-content/plugins/soundcloud-shortcode/soundcloud-shortcode.php
It worked fine for me.
add the '/' character as recommended and the problem simply goes away. That is, alter the URL in the soundcloud_iframe_widget() function to add '/' prior to the trailing '?
Thanks! that worked perfectly with chrome and safari, but I still have the issue with firefox. But doing that did the trick :
$url = 'https://w.soundcloud.com/player/' . '?' . http_build_query($options['params']);
Related
we are using:
TYPO3 8.7.27
RealUrl 2.5.0
following scenario - a user enters a link that does not exist within our site - so we expect the behaviour that a 404 page gets rendered - we managed to achive that but we do not have the correct status code because we used a simply redirect within the install tool:
[FE][pageNotFound_handling] = "REDIRECT:/404"
[FE][pageNotFound_handling_statheader] = "HTTP/1.0 404 Not Found"
we also use our 404 page for cHash comparison errors but thats just a sidenote.
so what happens is the user requests the data from the wrong url, we send the correct 404 followed by a redirect to a certain page.
how can we directly render a page in the first place, the url should stay the same and we just render our whole TYPO3 page (no static file) with the 404 text-information.
You should use this instead:
[FE][pageNotFound_handling] = "/404"
This will instruct TYPO3 to download the page at the given "URL" and output its content together with the expected 404 status code. Notice that it might be necessary to use an absolute URL here.
From the DefaultConfigurationDescription.php:
pageNotFound_handling
... String: Static HTML file to show (reads content and outputs with correct headers), e.g. "notfound.html" or "http://www.example.org/errors/notfound.html"
You can drop the pageNotFound_handling_statheader option since it defaults to 404.
So I have a website running on IIS on an address like this: myserver.com/mysite.
From here I made a rule to redirect the site to: myserver.com/mysite/path/to/file.
I did this using the HTTP redirection module to make a 302 redirect to path/to/file and that works fine.
The problem is that if I dont put the trailing slash / at the end of mysite I get a 404 error, so I used the built-in template AddTrailingSlashRule in the URL Rewrite module.
So if I disable the redirect, the trailing slash gets added at the end of the website just fine, but once I enable the HTTP redirect, it sends me to myserver.com/path/to/file/ and obviously that doesn't work, because I get the redirect first and then the rewrite.
Is there a way to change the "order" of the modules? Or is there a better way to achieve this?
Thanks for any help!
For anyone having this problem in the future, I ended up disabling the HTTP redirect and made a new rule using the URL Rewrite module.
It simply matches the ^$ regex and then redirects to path/to/file.
That rule goes after the trailing slash one so with or without the slash, it gets added and only then it gets redirected.
I'm working on a Slim Framework 3 project and can't believe I'm having trouble with redirects. According to their website this should work
return $response->withStatus(302)->withHeader("Location", "http://www.google.com");
Of course I'd replace, google with my own site, but neither works.
I'm hitting the route, my auth check is working fine, I make it to the redirect return statement, but nothing happens. The page is blank and doesn't redirect. I outputted $response to a file and this is what I saw
HTTP/1.1 302 Found
Content-Type: text/html; charset=UTF-8
Location: http://www.google.com
I've even tried $response->withRedirect() and got the same exact results. What am I missing?
UPDATE
I managed to get it working in middleware, but still can't get it working in routes and can't figure out why.
My company is embarking on a large website redirection at the moment and I decided it would give us the perfect opportunity to make the URL's more user and google friendly.
To give you a brief outline of the situation, I am the SEO guy and I am dealing with an external developer in order to redirect the website without hurting the current rankings in Google. I don't have much experience regarding sharepoint hence why I would really appreciate any assistance in understanding and knowing if there is a work around to my situation.
The website is using IIS7.5, they recently installed the URL Rewrite Module in order to create more user friendly URL's. My question is, by creating a more user friendly URL, does this cause an additional redirect?
For example: if a user types in www.domain.com this permanently (301) redirects to www.domain.com/pages/home.aspx.The developer told me that in order to rewrite the URL to display something more friendly (like www.domain.com/home) this will have to cause another permanent redirect. So in essence the process will look like this:
REQUESTING: http:// www.domain.com
SERVER RESPONSE: HTTP /1.1 301 Redirect
1) Redirecting to: http:// www.domain.com/pages/home.aspx
SERVER RESPONSE: HTTP /1.1 301 Redirect
2) Redirecting to: http:// www.domain.com/home
SERVER RESPONSE: HTTP/1.1 200 OK
Is this how the URL Rewrite Module really works? I would have thought that it would not have to create another redirect in order to create a more user friendly URL?
My second problem is this.... The redirect is happening on the same server. So here is essentially the situation:
www.old-domain.com
www.dev-domain.com
www.new-domain.com
The old-domain needs to be redirected to the new domain so we ran a test in order to see if the HTTP status codes were correct before going ahead with the project. So the developer redirected the dev-domain to the new-domain and the redirects look like this: (The developers comments in italic below)
REQUESTING: http:// www.dev-domain.com
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
1) Redirecting to: http:// www.new-domain.com/
SERVER RESPONSE: HTTP/1.1 302 Redirect
2) Redirecting to: http:// www.dev-domain.com/Pages/home.aspx
SharePoint’s alternate access mappings causes this to happen and there is no way around this.
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
3) Redirecting to: http:// www.dev-domain.com/pages/home.aspx
SERVER RESPONSE: HTTP/1.1 301 Moved Permanently
4) Redirecting to: http:// www.new-domin.com/pages/home.aspx
SERVER RESPONSE: HTTP/1.1 200 OK
The developer states the reason for redirecting back to the dev-domain then back to the new-domain is because of SharePoint's alternate access mappings and there is no way around this. Is that entirely true?
Any assitance at all will be GREATLY appreciated!
I'm trying to pass some variables to my facebook app from the url, i.e. using GET variable app_data like facebook wants.
At some point I've stopped getting the ['signed_request'] part of the $_REQUEST. When I print_r($_REQUEST) I'm getting: ['doc'], ['user'], ['__utmz'], ['__utma'] and ['session'] values, but not signed request :(
Any ideas of why this might be happening?
Check the tab/canvas url is EXACTLY the same as required. If there is a redirect to another page, then signed request and other values will not be sent. You can check using a browser sniffer, if a call to the page responds with a 300 (301/302 etc) redirect, then you need to change to what it redirects to.
Examples:
https://example.com/ may need to be https://www.example.com/ (add www., or remove www. depending on how server is set up)
www.example.com/ may need to be www.example.com/index.php (add index.php, or the right page).
Check you are using http:// and https:// correctly in the URLs, and that https:// returns a valid page.
I've only been able to get the signed request in https://, i get no request at all in http.
Currently have a bug on FB, but no word on fixing it yet; http://developers.facebook.com/bugs/264505123580318?browse=search_4eb3ef23eb18d6649415729
EDIT:
http://SITE.com was redirecting to http://www.SITE.com, so I was loosing the request variables.
Had a similar issue, for me it was as simple as a mismatch of the app id and app secret! However in facebook developers backend I have noticed that the URLs all need to have that trailing slash!
Some browsers do redirect your request to https automatically if you have been on this particular site on https so if you are in http mode on facebook there is situation:
facebook requests http version of your app, browser redirect this request of facebook to https and POST data and thus signer_request are gone in this process...
i see this problem in chrome 23, if you delete browsin data (particulary Deauthorize content licenses) app should run back on http