I am trying to decrypt a token using the google KMS tool.
Running it locally, for some reason, encryption seems to work but not decryption.
I am running the following code:
import base64
import googleapiclient.discovery
kms_client = googleapiclient.discovery.build('cloudkms', 'v1')
crypto_keys = kms_client.projects().locations().keyRings().cryptoKeys()
name = "projects/my-project/locations/my-loc/keyRings/my-kr/cryptoKeys/my-key"
request = crypto_keys.decrypt(name=name, body={'ciphertext': base64.b64encode("my text").decode('ascii')})
response = request.execute()
The last line returns a 400 error:
HttpError: <HttpError 400 when requesting https://cloudkms.g[...]ion:decrypt?alt=json
returned "Decryption failed: verify that 'name' refers to the correct CryptoKey.">
The name, however, actually seems to be correct.
Surprisingly enough, replacing the call to decrypt by encrypt, I obtain a valid output.
Am I missing an obvious mistake, or should I just open a issue on the project's github ?
EDIT:
I was trying to decrypt plain text, which of course does not make much sense (but the error message misled me somewhat).
Make sure that the ciphertext you're trying to decrypt was encrypted using the same key. In case you used another key to encrypt, KMS tells you that it could not find the key while actually the key was found but couldn't be used to decrypt the cipher.
I think the error message is "a bit" misleading.
Related
I'm trying to use the Unity AR/VR Toolkit with a SVF file I've created by following the test-2legged script. My understanding from this answer is that the script needs to be updated to use the new server (https://developer-api-beta.autodesk.io) and a URL-safe encoded URN everywhere. I've done that, but when I try to create the scene definition (PUT /arkit/v1/${urn}/scenes/${scene}) I get a 422 with a msg of "must be a valid Bearer token for the requested resource (TK1-003)" (I've tried giving the token all scopes listed in the Forge docs).
This works fine with the server in the non-modified test-2legged script. I'm operating on a file that's already in Forge so I'm not including the bucket, and I've experimented with including and not including the object ID; the default server (https://developer-api.autodesk.io) works fine with just an urn; the beta server I can't get to work no matter what I try.
I don't see any documentation for this endpoint so I'm not sure if it's use changed between the servers. As far as I can tell, in the toolkit I can't get SVF files created against the non-beta server (I get 404's for the meshes), so I'm assuming I should be on the beta server, but I can't get it to work.
I took a look into the source code and TK1-003 means that the Bearer token was either invalid, expired, and the token was missing the data:create data:write scoped for this operation. Note that in case, you call and API with an invalid token, the server bans you for couple of minutes.
If you still having issues, please let me know and I'll remote assist you.
What are the good choice for API error code response pattern?
Instead of using different codes indicating different type of error
100001 // username not provided
100002 // password not provided
100003 // password too short
...
I see some other use patterns like the following (non-sequential) ...
20000
20001
20004
20015
Are there any other recommendations?
In my experience developing and using web services, I have found that a strategy of using a combination of top-level HTTP status codes and lower level API error codes work reasonably well. Note that the lower level API error codes don't need to be integers, but can be any enumeration. For a well-known public example, AWS Simple Email Service (SES) uses this strategy of using both HTTP status codes and API level error codes. You can see a sample error code response for SES here. Note that although SES uses XML response error payloads, this strategy works equally well for JSON response payloads.
In my experience, there are a few things that you need to keep in mind when using this strategy:
Strive to return the correct HTTP response code: HTTP is a ubiquitous protocol and is no doubt understood by your web container. Its response codes fit naturally into REST web services. As such, leverage it! If your web service encounters an error condition, you should do your best to return the correct HTTP status code in whose context, the API error code has meaning. One my biggest headaches in debugging issues with web services occur when developers just unconditionally throw arbitrary (usually runtime) exceptions back up the stack. The result is that everything gets returned back to the caller as an HTTP 500 (Internal Server Error) status code even when that's not the case (e.g. the client sends garbage data and the server just can't process it. Some common HTTP status codes you might want to design for include:
400 Bad Request: There is an issue with the client's request. Note this error isn't just used for things like broken JSON syntax in a POST request, but it is also a legitimate response code for semantic issues as well (i.e. the JSON request payload conformed to the prescribed schema, but there was an issue with the data in the payload, such as a number being negative when it is supposed to be only positive).
401 Unauthorized: The caller's credentials were invalid (i.e. authorization error).
403 Forbidden: The caller's credentials were valid, but their access level isn't sufficient to access the resource (i.e. authentication error).
404 Not Found: The resource of the URL doesn't exist.
500 Internal Server Error: Something bad happened inside the server itself, this error could be anything.
502 Bad Gateway: An error occurred when calling downstream service.
503 Service Unavailable: A useful response code for when you get hammered with a ton of "happy" customers who are inadvertently DDOS'ing your service.
504 Gateway Timeout: Like the 502 status code, but indicates a timeout instead of an actual error with the downstream service, per se.
HTTP response codes are the top-level codes, and API error codes only have meaning within that context: By this, I mean that your API error codes are only meaningful for certain HTTP response codes. For example, in the table of SES error codes, each error code is only tied to a single HTTP(S) response code. The error codes ConfigurationSetDoesNotExist and InvalidParameterValue only make sense when a 400 Bad Request is returned by SES - it wouldn't make sense to return these status codes when a 500 Internal Server Error is returned. Similarly, if you were writing a web service that called downstream services and databases, you might have a FooDownstreamServiceTimedOut error code that you would return with a 504 Gateway Timeout HTTP status code when a downstream web service call timed out to the "Foo" web service. You might also have a MyDatabaseError error code that you would return with a 500 Internal Server Error HTTP status code when your query to the internal DB fails.
Have a uniform error code schema irrespective of status codes: Your clients need to be able to process your error content programmatically. As such, it needs to conform to a certain schema. Ideally, your API error code schema should include the error code (i.e. name or ID, etc.). You also probably want to include a natural language description of the error code and the ID/GUID of the request that you are responding to. For an example of an error schema, see this sample AWS SES response and schema. Additionally, you might also want to consider returning a client ID in the response. This is as much for your own benefit as the client's since it can help you drill down into the data to see if one particular client is getting a glut of particular errors vs. your other clients.
Consider returning natural language descriptions of the error codes in the response: To make things easier on your clients, you might want to consider not just returning the error code in the error payload, but a natural language description as well. This kind of behavior can immediately help confused and busy engineers who really don't care that much about your service quickly diagnose what's happening so that they can resolve the issue ASAP. btw, enabling engineers to quickly diagnose issues with your service increases the all-important "uptime" metric that your customers and managers will no doubt care about.
Don't feel obliged to use integers, use enumerations instead: The notion of "error codes" conjures up images of outdated technologies and codebooks where you had to look up what an error meant. It arose from the programming dark ages when engineers needed to fit all possible errors into a byte of space, or a nibble or whatever. Those days are gone, and your error code can be a string, likely without any meaningful impact on performance. You might as well take advantage and make the error code meaningful, as a means of keeping things simple.
Return info to clients that they might need to debug, but be mindful of security: If possible, return whatever debug info your clients may need. However, if your service potentially deals with sensitive information such as credit card numbers and the like, you probably don't want to pass that info around for obvious reasons.
Hope that helps.
A recommendation by the IETF (internet standards body) is using the application/problem+json mediatype.
Notable is that they don't use random numbers, they use strings (specifically uris) to identify errors.
This is a subjective question, but even if you don't use their format, I'd argue that username-not-provided is better in almost every way to 100001.
I would say this heavily depends on what kind of API you're providing.
I were to always include a field called ack or something similar in every response that has three states: failure, warning, success. Success obviously being everything went well. On warning, the request went through and the JSON will contain the expected output, but it will also include a warning string, or even better in case multiple warnings could occur an array called errors which consists of multiple objects containg code, string and type. This array will also be returned in case of failure, and nothing else but this array.
The array contains one object per error or warning, having a code (I would suggest going with your initial idea of 10001, 10002, ...) and a string explaining the error in a very short phrase (e.g. Username contains invalid characters). The type is either error or warning, which is useful in case of a failure ack that contains not only errors but also warnings.
This makes it easy to look up errors by their code (I would provide a page, also with an API, that contains all the error codes in a table along with their short and long description plus common causes/fixes/etc. - All this information should also be available via an API where they can be accessed by providing the error code) while still having a quick short text response so the user can tell what's wrong in most cases without having to look up the error.
This also allows for easy output of warnings and errors to the end user, not just the developers. Using my idea with the API call to get informations about an error, developers using your API could easily provide full information about errors to end-users when needed (including causes/fixes/whatever you see fit).
Instead of writing your own API standard from scratch adopt one of the already available, for example the JSON API standard:
If you’ve ever argued with your team about the way your JSON responses should be formatted, JSON API can be your anti-bikeshedding tool.
By following shared conventions, you can increase productivity, take advantage of generalized tooling, and focus on what matters: your application.
Clients built around JSON API are able to take advantage of its features around efficiently caching responses, sometimes eliminating network requests entirely.
If you decide to go with JSON API it has a section dedicated to errors and a few error examples.
For many years, many developent companies have created things like bitmask for errors, so they can encode multiple variables inside the error:
000 - all ok
001 - something failed with X
010 - something failed with Y
011 - something failed with X and Y
100 - something failed with Z
101 - something failed with X and Z
The limitation is that that limits the error space into however many bytes you decide on the encoding, like 16 or 32 possible combinations, it may be enough for you, or not.
You see this being common in COM+
https://learn.microsoft.com/en-us/windows/desktop/com/com-error-codes-1
I hope this helps.
Im getting the above error when sending the following body to the Box OAuth /token operation:
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&client_id=.............&client_secret=..........&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Im81NGFtcGR6In0=.eyJpc3MiOiIyOHRhZmZ0ejhlenhncnI3aTBocmZnMGlteTc2MjRuMyIsInN1YiI6IjU0MjA5MSIsImJveF9zdWJfdHlwZSI6ImVudGVycHJpc2UiLCJhdWQiOiJodHRwczovL2FwaS5ib3guY29tL29hdXRoMi90b2tlbiIsImp0aSI6IjE0NDYyMzA3MTgxMjM0NTYiLCJleHAiOjE0NDYyMzA3NjgsImlhdCI6MTQ0NjIzMDcxOH0=.ANwpzohhFyUmPMw1wh6kM8xzqsUanS3UIdEPN40hvpVDmzI9wS0fTpmxWvudGPPXXmeE0Cr+frbMx+R9V9DvzfJsGv2+mu1bqwsjHwPkOy06IigAvgiJPPFt9CuIdmY/H6pGtDpODfeau77KrT0OJhpQX9He4xy0maS26D7yc/5F3fyxZXHdG/XzTpx88xTpg2HbEJ5ImeZjxkFf6ZH4Un0ZY9TJ3TSEITTcqRxhAUN2qAttnX8H5jmKWyTE5U78+f1LzQz1lPjnQsj/BSRCrF2jkf7N0LfJwq3U1BXNBWiEZRW8wqvaTvZLpiODDsl6VuG/xs1m549wGVwyXCglJQ==
Now the JWT, of the assertion parameter, verifies correctly at jwt.io, and the Public key defined to Box verifies in the Box UI as well at jwt.io.
This indicates to me that what I'm sending is correct.
However Box has an issue..... any help would be very greatly received!
The problem seems to be in the public and private key generated using openssl in a DOS command prompt.
You can follow the instructions in this link:
https://box-content.readme.io/docs/app-auth
First of all, you have to download Cygwin tool: http://www.cygwin.com/
Then, in the Cygwin console you can launch the following commands:
For the private key
openssl genrsa -aes256 -out private_key.pem 2048
For the public key
openssl rsa -pubout -in private_key.pem -out public_key.pem
Be sure to include the full header and footer: '-----BEGIN PUBLIC KEY-----' AND '-----END PUBLIC KEY-----'
Once you've generated a public key, you will need to add it in your app's configuration.
When finished you'll get a Public Key ID.
You should be able to connect with your keys using the Box API.
var privateKey = File.ReadAllText("private_key.pem");
var boxConfig = new BoxConfig(CLIENT_ID, CLIENT_SECRET, ENTERPRISE_ID, privateKey, JWT_PRIVATE_KEY_PASSWORD, JWT_PUBLIC_KEY_ID);
var boxJWT = new BoxJWTAuth(boxConfig);
var adminToken = boxJWT.AdminToken();
Console.WriteLine("Admin Token: " + adminToken);
I hope this will help you
Right... this is extremely annoying!
Despite having created correct JWT's for other Public API's, and having the Header and body of the claim, and the signature verified by jwt.io, THE ONLY WAY to get box to accept my JWT was to use the JOSE4J utilities that the Box SDK uses.
This is really poor BOX - lift your game, and support JWT that are valid, not just the proprietary ones created by the JOSE4J classes!!!
The JWT in the example in the question that is the value of the assertion parameter appears to have its parts encoded using regular base64 encoding rather than base64url encoding prescribed by JWT/JWS. Many/most base64 implementations are very liberal in decoding and will happily accept base64 or base64url interchangeably. I'd guess that is why, despite that JWT not technically adhering to the specifications, it verifies okay when used directly at something like jwt.io. However, it might cause problems if not properly encoded when sent in the body of the HTTP request, which is expected to be application/x-www-form-urlencoded. The '+', for example, will decode to a space which will be ignored by many base64 decoders. The description in the error you're seeing doesn't seem to line up with that being the problem but it will corrupt the data and be a problem at some point (unless maybe you are url encoding the parameter values and just showing them unencoded in the question). Using base64url rather than base64 will mean that the value of the assertion parameter doesn't need to be url encoded and won't get messed up during url decoding. And base64url will be compliant with JWT. At least it would let you rule out some potential problems.
I had exactly the same problem, with the same error message from Box and the JWT verifying correctly in jwt.io.
It turns out that the problem was in Base64 vs Base64Url encoding. As Brian pointed, jwt.io can use both Base64 and Base64Url encoding, but Box requires Base64Url. The framework I am using uses Base64 by default and this was the problem and after forcing Base64Url on all parts of the JWT assertion, Box login succeeded.
I have this json feed.
I am unable to load this into Appgyver
I have set the following required settings:
- parameter app_name with the correct value
- added the reuired header X-DREAMFACTORY-APPLICATION-NAME
I always get the Oops, Unable to load resource's data model. error
Anyone who has a clue?
I am not very familiar with AppGyver, but I know it's been used with DreamFactory successfully by others. You have not provided enough information, but I will attempt to give you troubleshooting steps from the DreamFactory side.
First, are you definitely authenticating and passing a valid X-DreamFactory-Session-Token header? I can tell that you don't have guest access enabled (to make calls without authentication) because when I navigate to your link I receive a 401 with "There is no valid session for the current request."
Second, what is the call you're making from AppGyver? Is it a GET to simply list resources of a DB called vlaamse_vinyl, or what?
Finally, if you are passing X-DreamFactory-Application-Name in addition to the URI parameter ?app_name=vlaamse_vinyl this is redundant. Perhaps that is preventing your call from succeeding.
In my app, I'm running a following command on Python26 locally:
json.loads('"xxxx \ud83d xxxx"');
And it parses the string no problem.
But once I upload the code to the GAE server, the following error appears:
"Invalid \uXXXX\uXXXX surrogate pair"
Any suggestions? Could it be because I'm running python2.6 locally, and GAE is running on python2.5?
The string that causes problem is from an API from a well known site, so it's 100% percent valid. How do I force GAE to parse it correctly?
IMO the json implementations on your computer and on GAE differ. Here is a simplejson implementation which tells you what are the conditions to get the error.
Update: It looks like you have to prefix your string with u like u"xxxx \ud83d xxxx"