Reference:http://developer.android.com/google/gcm/demo.html
Server 401 when trying to send a message to my android device.
HTTP Status 500 - HTTP Status Code: 401
type Exception report
message HTTP Status Code: 401
description The server encountered an internal error (HTTP Status Code: 401) that prevented it from fulfilling this request.
exception
com.google.android.gcm.server.InvalidRequestException: HTTP Status Code: 401
com.google.android.gcm.server.Sender.sendNoRetry(Sender.java:177)
com.google.android.gcm.server.Sender.send(Sender.java:121)
com.google.android.gcm.demo.server.SendAllMessagesServlet.doPost(SendAllMessagesServ let.java:83)
javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
note The full stack trace of the root cause is available in the Apache Tomcat/7.0.29 logs.
Could anybody tell me how to solve?Thank you!
You should take a look at the GCM docs where it explains the GCM response: http://developer.android.com/google/gcm/gcm.html#response and troubleshooting the 401 error code: http://developer.android.com/google/gcm/gcm.html#auth_error
Description from the docs:
Authentication Error
The sender account that you're trying to use to
send a message couldn't be authenticated. Possible causes are:
Authorization header missing or with invalid syntax.
Invalid project number sent as key.
Key valid but with GCM service disabled.
Request originated from a server not whitelisted in the Server Key IPs.
So I would check to make sure that you are setting you authorization header properly and that you Google Project number is properly setup with GCM and accepting your servers IP.
Related
Is it possible to check Http status code in Apache configuration as %{REQUEST_STATUS} for instance?
There is no such thing as a "request status", and no way for a server to interact with a browser in the middle of serving an error message.
HTTP is not an interactive protocol; the browser sends a request, the server sends a response, and that's it. So if the browser sends a request, and the application crashes, the server can send a response with 500 and the error details, or a response with 401 requesting the user to log in. Either way, that's the end of the conversation.
When it receives a 401 response, the browser can't say "here's the login details, carry on with the current request", it has to make a new request. It can make an identical request, which might reproduce the error message; but the original error message is gone.
If the requirement is to show a different amount of detail to different users, you need some notion of optional authentication, so that the server can decide immediately whether to include the error details or not, without an extra round-trip to the browser. I would suggest either:
Have a list of IP addresses which the application can check against; if the IP address of the request is in the list, include the error details.
Have a custom login system where you can authenticate and set a "session cookie" in the browser. If the user has an active session cookie, include the error details.
This is an internal server error so it seems to be an issue on Pinterest's side. I've tried a few things but these accounts always seem to have the internal error.
Here's an example URL that caused the problem:
URL: https://api.pinterest.com/v1/boards/533324849561780294/pins?access_token=AX1gRVqQ2O-VNVVlWy1wAkz3JDvAFDeLJQ7Eom1C53m7hgAuWgAAAAA&fields=url,creator,created_at,counts,image,color,media,attribution,note,link
Exception Error: HTTP request failed! HTTP/1.1 500 INTERNAL SERVER ERROR
Response:
{"message": "A InstantContentBlockField was passed an unknown block_type: text", "type": "api"}
Remove "link" from the fields you will get normal response.
What is the system behavior of receiving a request to A restful API with a expired api_key in Moqui? Does the system send back the SC_UNAUTHORIZED error or something else?
The response is status with 500 internal server error.
I am working in an API . I want to throw detailed error messages to the user. Now i am in a situation to decide what kind of error code should be sent or how to explain user if any error occurs in the application internally. For example if database connection fails , what kind of http status code i want to send to the user ?
Can anyone help ?
An HTTP status code generally refers to the status of the HTTP request itself, not the status of the application handling the request. Therefore, most server-side errors are covered by 500 Internal Server Error. Any additional info about the error should be described in the response body. For APIs, the response body will often be JSON or XML, so you can use those formats for your errors. Something like this:
HTTP/1.1 500 Internal Server Error
[headers]
{"status":"error", "message":"The request failed due to database connectivity."}
There are, however, two cases I can think of when you might want another status code. If the user has requested an API method that is not implemented, you might want a 501 Not Implemented, and when there is a temporary service outage, you can use 503 Service Unavailable.
More info about server-side status codes here.
When the user ("Resource Owner") explicitly denies the auth request, this should be passed to the requesting client (something like that https://oauth2client.com/cb#error=access_denied).
What other errors should be passed to the 3rd-party-application? What about a (temporary) server error? Are there events that should not be called back with for security reasons?
Thanks!
Have you read the RFC?
See section 4.1.2.1. Error Response for the Authorization Code Grant. It outlines what error codes you can send back. server_error or temporarily_unavailable is probably what you are looking for. The OAUth2 security recommendations does not call out a reason for not sending them back.
If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.
If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following
parameters to the query component of the redirection URI using the
"application/x-www-form-urlencoded" format, per Appendix B:
error
REQUIRED. A single ASCII [USASCII] error code from the
following:
invalid_request
The request is missing a required parameter, includes an
invalid parameter value, includes a parameter more than
once, or is otherwise malformed.
unauthorized_client
The client is not authorized to request an authorization
code using this method.
access_denied
The resource owner or authorization server denied the
request.
unsupported_response_type
The authorization server does not support obtaining an
authorization code using this method.
invalid_scope
The requested scope is invalid, unknown, or malformed.
server_error
The authorization server encountered an unexpected
condition that prevented it from fulfilling the request.
(This error code is needed because a 500 Internal Server
Error HTTP status code cannot be returned to the client
via an HTTP redirect.)
temporarily_unavailable
The authorization server is currently unable to handle
the request due to a temporary overloading or maintenance
of the server. (This error code is needed because a 503
Service Unavailable HTTP status code cannot be returned
to the client via an HTTP redirect.)
Values for the "error" parameter MUST NOT include characters
outside the set %x20-21 / %x23-5B / %x5D-7E.