The following Chinese social media post links have been constructed in the correct format, but neither of them is working:
http://v.t.qq.com/share/share.php?url=https://hejuu.com/bonus/0/tencent&title=hejuu.com整套出租，单间出租，出售房产&pic=http://hejuu.com/pages/images/social.png
http://tieba.baidu.com/f/commit/share/openShareApi?url=https://hejuu.com/bonus/0/tieba&title=hejuu.com整套出租，单间出租，出售房产&desc=&pic=http://hejuu.com/pages/images/social.png
I've tried:
Encoding the query string parameters
Changing the submission URL to use HTTP instead of HTTPS
Getting someone in China to test the URL inside the firewall
Any help appreciated!
Tencent QQ resolves to 0.0.0.1 (even inside mainland-China), so the feature is deliberately broken.
The Baidu links appears to work now, however.
Related
I have a different URL for internal and external users. However, when I click on some of the links in the internal URL it redirects me to the external URL, is there anyway to ensure all links in the internal URL links to the internal URL and not the external URL? (e.g. clicking the logo in the banner links me to the external URL but other links on the dashboard links me to the correct URL)
We had a similar issue with ClearQuest in the past, and we ended up with the simplest solution - having internal users required to use the external URL.
I don´t know if it is possible to fix the problem this way in your case, but probably the error comes from general configuration of jira instance: make sure that in admin>system>general> URL Base attribute is correct. If you manage two Jira instances, you just have to sest it correctly on both.
I got the same problem with the test instance. And was weird to find that!!
Good luck
We have realized that this URL http://Keyword:redacted#example.com/ redirects to http://example.com/ when copied and pasted into the browser's address bar.
As far as I understand this might be used in some ftp connections but we have no such use on our website. We are suspecting that we are targeted by an attack and have been warned by Google that we are passing PII (mostly email addresses) in our URL requests to their Google Adsense network. We have not been able to find the source, but we have been warned that the violation is in the form of http://Keyword:redacted#example.com/
How can we stop this from happening?
What URL redirect method we can use to not accept this and return an error message?
FYI I experienced a similar issue for a client website and followed up with Adsense support. The matter was escalated to a specialist team who investigated and determined that flagged violations with the format http://Keyword:redacted#example.com/ will be considered false positives. I'm not sure if this applies to all publishers or was specific to our case, but it might be worth following up with Adsense support.
There is nothing you can do. This is handled entirely by your browser long before it even thinks about "talking" to your server.
That's a strange URL for people to copy/paste into the browser's address bar unless they have been told/trained to do so. Your best bet is to tell them to STOP IT! :-)
I suppose you could look at the HTTP Authorization Headers and report an error if they come in populated... (This would $_SERVER['PHP_AUTH_USER'] in PHP.) I've never looked at these values when the header doesn't request them, so I'm not sure if it would work or not...
The syntax http://abc:def#something.com means you're sending userid='abc', password='def' as basic authentication parameters. Your browser will pull out the userid & password and send them along as authentication information, leaving the url without them.
As Peter Bowers mentioned, you could check the authorization headers and see if they're coming in that way, but you can't stop others from doing it if they want. If it happens a lot then I'd suspect that somewhere there's a web form asking users to enter their user/password and it's getting encoded that way. One way to sleuth it out would be to see if you can identify someone by the userid specified.
Having Keyword:redacted sounds odd. It's possible Google Adsense changed the values to avoid including confidential info.
I'm adding Google Oauth2 to a Rails app, but have been unable to get past the early stages.
I've set up an app, and defined client ID and secret.But I'm getting Invalid parameter value for redirect_uri: Non-public domains not allowed: http://localhost/path/to/callback
What does this mean? Is this because I'm testing on a local dev environment?
Thanks for any ideas.
EDIT
This might be because the app's URI differs from the sending URI. But when I go to Google and try to authorize the path to my dev app, I get OAuth2 redirect is invalid. Is this a limitation of using a locally hosted app?
EDIT 2
The request I'm generating looks like this:
https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=###########&redirect_uri=http%3A%2F%2Fmyapp.dev%2Fusers%2Fauth%2Fgoogle_oauth2%2Fcallback&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile&approval_prompt=&access_type=offline
Is this correct. I've tried this with client_id including and excluding the .apps.googleusercontent.com section. Neither seems to work.
I was getting the redirect error for my python / tornado app running on ubuntu. Using localhost didn't work as the accepted answer highlighted. Google wants a public domain.
My solution was to piggyback "example.com" which is public and create a sub domain in my /etc/hosts file. The sub domain would work on my local dev box and google would be happy with the example.com domain. I registering the redirects via the google console and the redirect worked successfully for me.
I added the following to my /etc/hosts:
192.168.33.100 devbox devbox.example.com
In my case the IP was that of my machine. I could also have used 127.0.0.1 instead.
My Google API console (https://code.google.com/apis/console) set up for a new client ID was:
"Application Type: Web Application".
Via "Your site or hostname (more options)":
In "Authorized Redirect URIs" I entered http://devbox.example.com/
In "Authorized JavaScript Origins" I entered http://devbox.example.com/
Using xip.io you can provide a public url to redirect to like http://your_pow_app.192.168.0.1.xip.io/user/auth/google_oauth2/callback
Tested and working.
I used my public hostname. It helps if you have a static IP address. I used http://www.displaymyhostname.com/ to get my hostname. I plugged it straight into the Authorized JavaScript origins field when I created a new Web Application Client ID.
P.S. My hostname looked something like this: 111.111.111.111.static.exetel.com.au
This is my answer to a related question https://stackoverflow.com/a/23517146/1320083
For anyone else finding this, my problem was combination of several things.
I could not get callbacks to work on a local machine. The console API console suggests it is possible, but I couldn't get it working. Not sure of this is down to the service, or to my network/ connection/ firewall/ etc.
In the API console you must specify the full redirect URI, not just the root url back to your app.
Google lists scope parameters here https://developers.google.com/gdata/faq#AuthScopes. It seems this information is outdated, and the correct format for these is now https://www.googleapis.com/auth/plus.me, https://www.googleapis.com/auth/youtube, etc. Maybe someone else can confirm this?
I had a few other things going on as well. I had written a full explanation on another of my questions here on SO. Unfortunately my comments were deleted instead of moved by a moderator because I posted in the wrong place. I can't now remember all that I wrote. For others facing similar issue, feel free to comment, it may jog my memory so I can offer some ideas.
Error redirect_uri_mismatch - This error can occur when you entered an incorrect bundle ID in your Google Developers Console project that does not match your app's bundle ID. Check that your client ID and bundle ID match the values that are displayed in the Developers Console.
For me it was the function that built up the google url. I put line breaks in the string, once I removed the line breaks the url worked again.
I faced this issue but found it was really not an issue. As explained in my blog you can use the public redirect URI even when you are working on your localhost development machine. Google will just return the authorization code to the public URI where you can cut and paste it to your local machine.
I'm seeking for solution how to isolate widget included by partial to main site. Issue appear when user access site with https. Ie 6,7 shows security confirmation dialog (part of website resources are not in secure zone).
First of all I download twitter widget on our side, also I download all CSS and pictures. Then I patched widget JS to point onto downloaded resources. But still has not luck with security warning :( I guess the reason of this issue is AJAX request to twitter, but there is no idea how to sole it. (Just to create some kind of proxy on our side).
Thank you for attention.
You just need to host the .js file on your server, and link to that. That is all.
The script auto detects SSL and will make requests to https://twitter-widgets.s3.amazonaws.com/ instead of http//widgets.twimg.com/ dynamically depending on your scenario.
Hope that helps!
geedubb
I got the Twitter Widget to work over HTTPS (SSL) by doing the following:
Save every image, css, and javescript file on my local webserver
Changed every "http" to "https" in the javascript AND in the css
The last piece was tricky. https://twitter.com/statuses/user_timeline.json brings back data that already includes "http"; namely avatars and the profile image. So, I found about four places in widjet.js that used the user_timeline.json data. I hardcoded an image url where ever that "http" data was used. Searching "src" will located all of those places.
It's an ugly fix, but it worked.
You can use a sniffer like HttpWatch to debug this--watch the requests going by and see which ones start with http instead of https. It may be possible to just change the urls you use to point to https://twitter.com, not sure about how your widget works.
thanks Keshar, worked for me. I came to the same conclusion that all http requests had to be https to prevent the IE security warning and also display the twitter feed. I used the live HTTP headers firefox plugin which helps for showing any non-secure http requests, such as the JSON requests.
Jon
If you look through the script there are calls to a https site. If you simply replace the protocol/domain with
https://twitter-widgets.s3.amazonaws.com/
instead of
http//widgets.twimg.com/
it works and you don't have to do anything else.
I faced a problem some time back on a particular website. It has given many hyperlinks on it to other sites. e.g. of one such URL is:
http://http//example.com/a9noaa.asp
It is clearly incorrect (http comes twice) URL so when one clicks on it there is a page error like "Address not found".
But when one copies the link location and pastes it in the browser’s location bar, it loads that new page correctly. So it’s the problem of incorrect URL being mentioned in the hyperlink.
Will it be possible to make browser check for basic sanity of the URL being accessed like checking that:
word http is present only once,
colon is typed correct,
no unusual character at beginning of URL,
double backlashes are correctly present, etc.
Or that the URL being typed in the address bar and automatically correct the errors in it?
Can any client side code be present to make a internet browser achieve this functionality? Is it possible?
Or are there any plugins for popular browsers (Firefox, IE) already available to achieve this?
Thank you.
-AD.
First of all, http://http//example.com/a9noaa.asp is a valid URI with http as the scheme, the second http as the host name and //example.com/a9noaa.asp as the path. So if it’s not invalid, the browser has no need to correct it.
Now let’s look at the location bar. Most user friendly browsers do some error correction if the location that has been entered is invalid. One of that correction measures is to prepend the string with http:// if that’s not present. So you just have to type example.com to request http://example.com.
Another correction measure is to complete unknown host names with http://www. and and .com before and after the entered string. So you just have to type example, hit enter and you request http://www.example.com.
But any error correction outside the location bar can especially in hyperlinks can be crucial. Take this for example: A guest enters his/her website URI in a guestbook entry but ommits the http://. Now that value is used in a hyperlink but the missing http:// is not prefixed. So the link might look like this:
Website
If you click on such a link, the relative URI of that link would be resolved to an absolute URI using the current document’s URI as the base. So the link might be expanded to http://some.example/guestbook/example.com. Who hasn’t experienced that?
But correcting that missing http:// in the browser is fatal. Because the auther might have intended to reference http://some.example/guestbook/example.com instead of http://example.com that the browser would expect.
So to round it up: Correcting the user’s location bar input suitable when there is something missing (e.g. the http://). But doing that on every link is not.
The URL you posted is not "incorrect", it is valid. Hostnames can take many forms, such as http://localhost/ or http://http/ as well as the more common http://example.com
If you don't include http:// or another protocol in a web link, then the browser assumes you are using a relative link. For example...
link
...will link to http://yoursite.com/www.example.com, because this is a perfectly valid URL - you can name a file www.example.com.
I would recommend contacting the website in question to fix their error. No browsers will correct this automatically.
It really shouldn't be up to the browser to correct mal-formed URLs. A URL is supposed to be a unique identifier of some page. The one doing the linking to the page should take care to link to the correct page. There must be no guesswork involved in opening a URL.
That said, some browsers are better than others. Of the top of my head I think IE won't understand "localhost:8888/test" (no protocol given and not standard port 80), but Firefox will at least try to access it via "http://localhost:8888/test". This kind of best-guess filling-in-the-blanks is fine I think, any further auto-correction would be doing too much.
Safari for example will try to auto-guess domain names for you. If "apple/safari" yields a DNS error, it'll automatically try to complete the address to "apple.com/safari". With your URL it might try to complete it to "http://http.com//example.com/a9noaa.asp", which might yield a page if http.com exists. There's just no one way of doing it, therefore it shouldn't be done at all.