I'm trying to make an application to get data from the Piwik API to process and analyse. I'm having trouble getting the API URL to work properly for our specific site (our Piwik is a multi-site installation, our site is identified by a segment variable, specifically customVariableValue1=9).
(I've replaced our domain and token with placeholders)
This URL works fine:
https://example.com/piwik/?module=API&method=Actions.getPageUrls&idSite=3&date=yesterday&period=day&format=json&token_auth=mytoken
However when I try to access this:
https://example.com/piwik/?module=API&method=Actions.getPageUrls&idSite=3&date=yesterday&period=day&%20segment=customVariableValue1%3D%3D9#&format=json&token_auth=mytoken
I get this error: <error message="You can't access this resource as it requires an 'view' access for the website id = 3."/> back. The token I am using is definitely correct so I have no idea why it's coming back with that error.
Any help would be greatly appreciated! :)
You have token_auth after # sign so it is interpreted as fragment identifier, not as part of query.
This URL should be valid:
https://example.com/piwik/?module=API&method=Actions.getPageUrls&idSite=3&date=yesterday&period=day&format=json&token_auth=mytoken&segment=customVariableValue1%3D%3D9#
UPDATE
App Engine SDK 1.9.24 was released on July 20, 2015, so if you're still experiencing this, you should be able to fix this simply by updating. See +jpatokal's answer below for an explanation of the exact problem and solution.
Original Question
I have an application I'm working with and running into troubles when developing locally.
We have some shared code that checks an auth server for our apps using urllib2.urlopen. When I develop locally, I'm getting rejected with a 404 on my app that makes the request from AppEngine, but the request succeeds just fine from a terminal.
I have appengine running on port localhost:8000, and the auth server on localhost:8001
import urllib2
url = "http://localhost:8001/api/CheckAuthentication/?__client_id=dev&token=c7jl2y3smhzzqabhxnzrlyq5r5sdyjr8&username=amadison&__signature=6IXnj08bAnKoIBvJQUuBG8O1kBuBCWS8655s3DpBQIE="
try:
r = urllib2.urlopen(url)
print(r.geturl())
print(r.read())
except urllib2.HTTPError as e:
print("got error: {} - {}".format(e.code, e.reason))
which results in got error: 404 - Not Found from within AppEngine
It appears that AppEngine is adding the schema, host and port to the PATH portion of the url I'm trying to hit, as this is what I see on the auth server:
[02/Jul/2015 16:54:16] "GET http://localhost:8001/api/CheckAuthentication/?__client_id=dev&token=c7jl2y3smhzzqabhxnzrlyq5r5sdyjr8&username=amadison&__signature=6IXnj08bAnKoIBvJQUuBG8O1kBuBCWS8655s3DpBQIE= HTTP/1.1" 404 10146
and from the request header we can see the whole scheme and host and port are being passed along as part of the path (header pieces below):
'HTTP_HOST': 'localhost:8001',
'PATH_INFO': u'http://localhost:8001/api/CheckAuthentication/',
'SERVER_PORT': '8001',
'SERVER_PROTOCOL': 'HTTP/1.1',
Is there any way to not have the AppEngine Dev server hijack this request to localhost on a different port? Or am I not misunderstanding what is happening? Everything works fine in production where our domains are different.
Thanks in advance for any assistance helping to point me in the right direction.
This is an annoying problem introduced by the urlfetch_stub implementation. I'm not sure what gcloud sdk version introduced it.
I've fixed this by patching the gcloud SDK - until Google does.
which means this answer will hopefully be irrelevant shortly
Find and open urlfetch_stub.py, which can often be found at ~/google-cloud-sdk/platform/google_appengine/google/appengine/api/urlfetch_stub.py
Around line 380 (depends on version), find:
full_path = urlparse.urlunsplit((protocol, host, path, query, ''))
and replace it with:
full_path = urlparse.urlunsplit(('', '', path, query, ''))
more info
You were correct in assuming the issue was a broken PATH_INFO header. The full_path here is being passed after the connection is made.
disclaimer
I may very easily have broken proxy requests with this patch. Because I expect google to fix it, I'm not going to go too crazy about it.
To be very clear this bug is ONLY related to LOCAL app development - you won't see this on production.
App Engine SDK 1.9.24 was released on July 20, 2015, so if you're still experiencing this, you should be able to fix this simply by updating.
Here's a brief explanation of what happened. Until 1.9.21, the SDK was formatting URL fetch requests with relative paths, like this:
GET /test/ HTTP/1.1
Host: 127.0.0.1:5000
In 1.9.22, to better support proxies, this changed to absolute paths:
GET http://127.0.0.1:5000/test/ HTTP/1.1
Host: 127.0.0.1:5000
Both formats are perfectly legal per the HTTP/1.1 spec, see RFC 2616, section 5.1.2. However, while that spec dates to 1999, there are apparently quite a few HTTP request handlers that do not parse the absolute form correctly, instead just naively concatenating the path and the host together.
So in the interest of compatibility, the previous behavior has been restored. (Unless you're using a proxy, in which case the RFC requires absolute paths.)
I have been facing the same problem from Google Cloud API Console for over a day now.
I tried to add a new redirect_uri for an old project to use it in my webapp but it gives me "redirect_uri mismatch" error. Old redirect uri still work as they used to.
I even tried creating a fresh project from the start and then registered a new application. This now gives me "invalid_client" error via google oauth.
If the old redirect_uri redirect as they should, then why doesn't the new one? Does something else need to be done when addding a new redirect uri?
Your errors are all self explanatory, so you simply need to carefully retrace your steps and check typing, that you are using the correct client id with the appropriate urls.
it gives me "redirect_uri mismatch" error.
The uri must match character for character. eg. watch for http(s) and trailing slash
This now gives me "invalid_client" error via google oauth.
Either you forgot to enable the API or you haven't correctly installed the new client ID in your app.
Does something else need to be done when adding a new redirect uri?
NO. Just make sure it exactly matches the URL you are passing.
It's sometimes easier to switch back to the old API Console. There is a faint grey link at the bottom of the screen in the new cloud console.
This looks like a bug.
See Newly created Oauth Client IDs don't work for what seems like a successful workaround.
I am testing QuickBooks Online API by using the source code from the following URL:
https://github.com/consolibyte/quickbooks-php
When I test the diagnostics.php http://mydomain.info/qb/docs/example_app_ipp_v3/diagnostics.php
I got the following error:
Warning: array_merge(): Argument #2 is not an array in /home/mydomain.info/public_html/qb/docs/example_app_ipp_v3/diagnostics.php on line 15
The connection is fine.
Please advise
If $creds is empty, it means that you have not yet established a valid OAuth connection to Intuit's servers.
You need to do that before anything is going to work. If you're just trying to get rid of the error, just cast $creds to an array.
To establish a connection, click the "Connect to QuickBooks" button that's shown on the /index.php script when you visit it in a browser. You'll be walked through the OAuth setup process (make sure you've changed the URLs, app token, and OAuth credentials in config.php first, and configured your URLs in your IPP app as well on Intuit's site).
Regarding your other questions:
$the_username and $the_tenant can be left at their defaults for testing.
In production, you will likely NEVER use $the_username (it's used only in very specific special circumstances). $the_tenant should be set to your unique tenant identifier within your SaaS app (or, if you're not a SaaS app, just leave it at it's default).
There are two application servers and a switch. When i access application by using application server ip it works fine. However if i use switch ip in my url Bad request error throws up only for firefox and chrome for a few links only.
Here is a detailed explanation & solution for this problem from ibm.
Problem(Abstract)
Request to HTTP Server fails with Response code 400.
Symptom
Response from the browser could be shown like this:
Bad Request
Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.
HTTP Server Error.log shows the following message:
"request failed: error reading the headers"
Cause
This is normally caused by having a very large Cookie, so a request header field exceeded the limit set for Web Server.
Diagnosing the problem
To assist with diagnose of the problem you can add the following to the LogFormat directive in the httpd.conf:
error-note: %{error-notes}n
Resolving the problem
For server side:
Increase the value for the directive LimitRequestFieldSize in the httpd.conf:
LimitRequestFieldSize 12288 or 16384
For How to set the LimitRequestFieldSize, check Increase the value of LimitRequestFieldSize in Apache
For client side:
Clear the cache of your web browser should be fine.
If you use Apache httpd web server in version above 2.2.15-60, then it could be also because of underscore _ in hostname.
https://ma.ttias.be/apache-httpd-2-2-15-60-underscores-hostnames-now-blocked/
I just deleted my stored cookies, site data, and cache from my browser...
It worked. I'm using firefox...
Make sure you url encode all of the query params in your url.
In my case there was a space ' ' in my url, and I was making an API call using curl, and my api server was giving this error.
Means the following url
http://somedomain.com?key=some value with space
should be
http://somedomain.com/?key=some%20value%20with%20space
THIS IS CAUSED BY TOO MANY COOKIES!
To SOLVE - Chrome: go into 'developer mode' -> ctrl + shift + i
On top you will see console, network and LITTLE BUTTON THAT LOOKS LIKE ARROWS >>> click on that for APPLICATION
On Left, under STORAGE, find COOKIES.
There will be little DOWN ARROW indicating a drop down, click on this.
now you will see the website something like: www.investing.com
RIGHT CLICK IT and select Clear
Reload.
Works!
Alternatively, clear cookies and cache in a traditional way, and it will work too.
In my case is a cookie-related issue, I had many cookies with extremely big values, and that was causing the problem.
You can replicate this issue here on stackoverflow.com, just open the console and type this:
[ ...Array(5) ].forEach((i, idx) => {
document.cookie = `stackoverflow_cookie${idx}=${'a'.repeat(4000)}`;
});
What is that?
I am creating 5 cookies with a string of length or value of 4000 bytes; then reload the page and you will see the same issue.
I tried it on google.com and you'll get the error but they automatically clear the cookies for you, which is a nice fallback to start fresh.
I was testing my application with special characters & was observing the same error. After some research, turns out the % symbol was the cause. I had to modify it to the encoded representation %25. Its all fine now, thanks to the below post
https://superuser.com/questions/759959/why-does-the-percent-sign-in-a-url-cause-an-http-400-bad-request-error
I'm a bit late to the party, but bumped in to this issue whilst working with the openidc auth module.
I ended up noticing that cookies were not being cleared properly, and I had at least 10 mod_auth_openidc_state_... cookies, all of which would be sent by my browser whenever I made a request.
If this sounds familiar to you, double check your cookies!
in my case:
in header
Content-Typespacespace
or
Content-Typetab
with two space or tab
when i remove it then it worked.
in my magento2 website ,show exactly the same error when click a product,
my solution is to go to edit the value of Search Engine Optimization - URL Key of this product,
make sure that there are only alphabet,number and - in URL Key,
such as 100-washed-cotton-duvet-cover-set,
deleting all other special characters ,such as % .
I got Bad Request, Your browser sent a request that this server could not understand
when I tried to download a file to the target machine using curl.
I solved it by instead using scp to copy the file from the source machine to the
target machine.
If you are getting this error on the WordPress website, check the below solution.
Corrupted Browser Cache & Cookies: Delete your Cookies and clear your cache
Restart your server
For GET Request make sure that passing parameters are url encoded.
if you are using php you can use urlencode function
If you have this same problem and none of the other solutions worked, please check again the url.
In my case it was a space in the end, when it was added to the Cronjob, someone also copied a blank space by accident.
check your data types are correct or not.
for ex: if you send the file, you need to consider to send the full object of the file