Python Graphene. Authorization error handling - vue.js

I have the following environment:
Frontend
#vue/cli 4.1.2
vue-apollo 3.0.2
Backend
python 3.8
django 3.0.2
graphene-django 2.8.0
django-graphql-jwt 0.3.0
My problem is handle the auth errors when the token has expired. For example, if I request the query me when the token is expired:
def resolve_me(root, info):
user = info.context.user
if user.is_anonymous:
raise GraphQLError('Authentication failure!!')
return user
in the link of the apollo client receive a 200 and the networkError object is empty and graphQLErrors object don't provide the status code.
how you manage this scenario?
Thanks by advance.

Check out this comment https://github.com/graphql-python/graphene/issues/142#issuecomment-221290862
As far as I can tell from the GraphQL spec there is no discussion of http response codes at all. The status codes of HTTP are strongly tied to rest principles. It's not clear to me whether GraphQL APIs should distinguish between 2XX and 4XX status codes.
Most notably, you can batch multiple mutations into the same request to the server. If one successfully creates a resource (201), one mutates a resource (200), one fails validation (400) and another the target object does not exists (404), what should the return value from the API be?
At the moment, GraphQL APIs seem to err on the side of 200 unless the server blows up, in which case 500.

Related

Why am I getting multiple response codes to one authentication POST request?

I'm working with an API and recently something went wrong with the authentication.
The API uses jwt authentication, and when POSTing the client jwt request, instead of getting back an auth jwt, I'm getting a 401 (final) status code (or 404, depending on the library I use to handle requests...), but I'm also getting 407 and 200 when setting a verbose traceback?
I'm pretty new to handling HTTP requests so I'm curious how exactly that might be happening, where are those additional two status codes coming from?

Flutter Google Sign In Couchbase Authentication Code Flow

As we are migrating our app from Firebase to Couchbase, we also need to change the authentication part. We are using the google_sign_in package and would like to continue using it to have the native Google Sign In popup. Using the package we can get a serverAuthCode, which from my understanding we can then send to the _oidc_callback endpoint of Couchbase Sync Gateway. First I had to set disable_callback_state to true in the Sync Gateway configuration ("DisableCallbackState determines whether or not to maintain state between the /_oidc and /_oidc_callback endpoints."). However, when I now send the serverAuthCode to the _oidc_callback endpoint, I get the following error with status code 500:
body: {"error": "Internal Server Error", "reason": "Failed to exchange token: oauth2: cannot fetch token: 400 Bad Request\nResponse: {\n \"error\": \"invalid_grant\",\n \"error_description\": \"Bad Request\"\n}"}
I assume it is because the login was done using the package and not through the browser with a redirect to the app afterwards. Now I have no idea how to do this correctly though, that I sign in with the google_sign_in package and then use the code to get the tokens from the Sync Gateway. I can't find any helpful information for this problem.
I would be very happy if someone could help me, possibly in a call. Maybe this way something like this can be solved faster.

Invoking wso2greg Artifcat Rest API via wso2api manager is not working - any ideas to fix

UPDATED QUESTION to clarify more.
I have two servers : wso2greg containing custom artefacts and wso2am (api manager).
The gouvernance register is intended to be used internally (intranet) and some of it's feature are intended to be exposed externally and acceded via it's rest API.
In order to manage wso2greg API accesss, we used an wso2am (api manager) server, where we did define an API that act as a proxy for the wso2greg API.
In our experiments, we found the strange behaviour described below :
Successfully direct calling wso2greg artefact rest api (the exact url is
https://localhost:9443/resource/1.0.0/artifact/_system/governance/myartifact/art1 and i'm following the documentation of this REST API from here https://docs.wso2.com/display/Governance520/Resources+with+REST+API ) using postman. The API reacts as described in the documentation.
Error 500, reported on wso2greg server, when calling the same REST API, but via API manager (using publisher application).
So as a summary :
Directly calling wso2greg rest API woks fine and a got results back
Adding this working API, in wso2am and than calling it gives always error 500.
As extra information:
Tested with other wso2greg REST API , such as "rating" or "comments" and I was able to call it successfully either directly or throw Api manager.
Tried to get information related to default wso2greg artifacts such as restservice, but i got exactly the same pb when (error 500) interagting with API manager.
Working with the last version of both products : wso2greg version 5.2.0 and wso2am version 1.10.0
Please advice, or clarify how could i debug this internal error in wso2greg.
Regards,
I hope your not using G-Reg + APIM feature installed version. I presume your using separate G-reg 5.2.0 and APIM x.x.x. Since your using the second option you can't use G-Reg REST API with APIM, therefore you have to use APIM REST API instead.
Get an API
Description: Get details of a specific API.
URI: http://localhost:9763/publisher/site/blocks/listing/ajax/item-list.jag
URI Parameters: action=getAPI&name=xxx&version=xxx&provider=xxx
HTTP Methods: POST
Example:
curl -X POST -b cookies http://localhost:9763/publisher/site/blocks/listing/ajax/item-list.jag -d "action=getAPI&name=PhoneVerification&version=1.0.0&provider=admin"
Please follow this link to see all the api usage.
Thanks #thusharaK for providing help.
The solution was to add Message Mediation Policies which forces json header on output.
Now i got my correct response from API manager (in fact, i got a binary response in test console and a json response in postman) .

Gerrit 2.8.5 retrieving xGerritAuth from http request

I am a bit of a newbie to Gerrit customization and running tests against Gerrit server.
In 2.4 version of Gerrit, an http login request (in my case from python file) would return a result that had the xsrfToken field and value as members of gerrit_hostpagedata (e.g. in request result you would see gerrit_hostpagedata.xsrfToken=<some value>).
In 2.8, this has changed so that xGerritAuth is now the field for the token value. However, the response from the server to my http login request (via python) is not returning the xGerritAuth field/value pair.
In the web UI for Gerrit, if I view the source when logging in, I can see the xGerritAuth field/value pair.
So I am wondering is there a way to get the xGerritAuth value returned in the response to the http login request?
NOTE that the gerrit/common/data/HosptPageData.java has changed to reflect the new token name (xGerritAuth).
thx
-mike
You need to parse the xGerritAuth out of the HTML response (which you get when you send your credentials to /login/). I do exactly that in my gerrit-rest-java-client. Check out this code. (tryGerritHttpAuth and extractGerritAuth).
Another way: use the (new) REST API of Gerrit. There you can use the HTTP credential you set in your Gerrit account settings. See REST API’s documentation.

How to show the internal server errors to the user?

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.