What will happen if we call update for a non-existing resource in OKTA SCIM API using PUT ?
Does it return 404 or is it create a new user?
I have no experience with Okta's SCIM implementation, but per the SCIM RFC, the correct response is a 404. When updating via PUT or PATCH, you would be targeting a specific object via the ID value (ie: scim.app.com/scim/v2/users/12345). If an object possessing the ID value provided does not exist, a 404 should be returned by the SCIM endpoint.
::EDIT:: The above answer is incorrect, as my interpretation of the SCIM RFC was incorrect. The correct response is 400 Bad Request with an error message of invalidValue, as the user ID value specified in the PUT operation not being present means that the value provided (Ex: /Users/123) is incompatible with the operation being attempted (update of an existing object via PUT). ::END EDIT::
Relevant sections of the RFC: https://www.rfc-editor.org/rfc/rfc7644#section-3.2 (SCIM Endpoints and HTTP Methods) calls out:
PUT Modifies a resource by replacing existing attributes with a
specified set of replacement attributes (replace). PUT
MUST NOT be used to create new resources.
Related
This happens in the API Explorer and using the .NET client API. In the API Explorer, I was trying to use the query param, but eventually I just removed it and now send the request with no params, and it still turns around 400 even though I am authenticating successfully with OAuth2 in browser.
Why is this endpoint broken?
https://developers.google.com/admin-sdk/directory/v1/reference/users/list
The problem was the customer field was not filled in. It must contain a valid customer id. Once I populated that, it worked.
Really wish Google would work on providing better error feedback and improve their docs. This field (as of today) is still listed as optional.
As the documentation says:
either the customer or the domain parameter must be provided
I tried to specify domain name and it worked.
Found myself opening a couple of functions for access to users with invalid session tokens. The only way I could find to do that is to intercept the request using a bodyParser before Parse gets the request and removing sessionToken from the request.
Now trying to do a better job managing authorization to all functions - My question are:
can I relax the requirement that if a sessionToken is included it must be valid in any other way? Is session token validation done using a default validationHandler that can be replaced or is that done elsewhere?
to control access to cloud functions, is there anything like ACL roles? does cloud function's "validationHandler" accept only param? or can I inspect the user object as well?
Yes. In parse-server you can make sure that the sessions are valid because if you will try to run any CRUD operation with invalid session you will get http 403 error that your session is not valid or expired. You can control on the "Length" of your session by changing the sessionLength property in your parse-server app. The default is 1 year
There is no control access to cloud functions but you can check if a logged in user trigger this function by checking if the request.user is not undefined. Cloud functions can get only params in key-value pairs and those params cannot be Parse Objects. if you want to send ParseObject you can send the objectId of the parse object and then query for it in cloud code to get the full object. You can always access the user context in request.user (only if cloud code was triggered by the user). If you still want to "protect" your cloud code you can check if the calling user have a Role by query the Role DB and check if the user is contained there.
I am facing this error sometimes (not always). I create a resource and a method in an API Gateway function. Then I map it to a Lambda function. On testing it there itself, everything works fine.
Now I add a custom authorization function to the method. Now, if I test it there,
If I do not provide the Authorization header, it works (since it is not deployed yet. After deployment, it would require the Auth header)
If I, however, provide the Authorization token, I get the error:
The request signature we calculated does not match the signature you
provided. Check your AWS Secret Access Key and signing method. Consult
the service documentation for details.\n\nThe Canonical String for
this request should have
been\n'POST\n/2015-03-31/functions/arn%3Aaws%3Alambda%3Aus-eas
More details: The lambda function belonging to this method was deleted. Then I re-created the function with the same name. And noticed that the method was deleted when the API was deployed. So I re-created the mapping and mapped it to the Lambda function. Since, then I am facing this issue. I am sure if I change the name of the Lambda, it might fix the issue. But I think it's a bug with AWS and not at my end. Need to clarify if there is anything I am doing wrong ?
It looks like the currently deployed version of the API is forwarding the Authorization header from the method request to the integration request (Lambda). If you are trying to fix the current state of your API, then I suggest removing the Authorization header from the method request, which will also remove it from the integration request. This should fix the Lambda signature errors.
If you're trying to use the custom authorizer on a method, you don't need to set up the Authorization header in the method request. You just need to set the authorizer identity source as 'method.request.header.Authorization'
I want to add a user to a group through the API. The proper endpoint should be:
https://www.yammer.com/api/v1/group_settings/process_additions , but keep getting a 404.
I found this, describing my exact problem, but no answers:
I want to join users except current login to yammer group. or I want to invite them to join yammer group using javascript sdk by yammer. I found one way of doing that by following
Makes a POST to: same call as above
id: GROUP_ID
invites[ids][]: USER_ID
invites[emails][addresses]:
I don't know how to call it. I tried to call that URI but it gave me error like
"No 'Access-Control-Allow-Origin' header is present on the requested resource" can any one tell me how to pass that data to request call ?
So: How to call https://www.yammer.com/api/v1/group_settings/process_additions ?
Looks like there is an authenticity_token param missing in your URL. You must supply that parameter.
This URL works, but note that it is not documented / supported, and could potentially change at any time:
https://www.yammer.com/insert_yammer_network_name/group_settings/process_additions/isert_groupID.json?id=isert_groupID&invites[ids][]=&invites[emails][addresses]=insert_email#domain.com&auto_add_invitees=true&authenticity_token=insert_oauth-token
Modify the above format with your details, copy it into a browser URL, hit enter, and you should get the following response {"status":"ok"}, or {"already_member":"true"} if the the user is already a member of the group.
Note that you can't make REST calls to https://www.yammer.com/* as it will result to CORS error. Use https://api.yammer.com/api/v1/ as your base URL instead.
===========================
The above solution is no longer valid. Use the impersonation method instead as it is supported/documented by yammer.
I am not able to get a request token from the oauth/initiate page because it says page not found. What could be the problem?
I have created an oAuth customer, given the appropriate REST roles and attributes. Also, appended the consumer key, secret, nonce etc. in the authorization for the oAuth request.
What am I missing?
Oauth will give you page not found if the request params are incorrect. It's likely your client isn't sending the parameters correctly, or your signature doesn't match the one Magento is calculating.
I added some temporary logging to the OAuth server to try and track down the issue.
Add this to file app/code/core/Mage/Oauth/Model/Server.php after line 594, it will help you see what specific oauth error is being raised
Mage::log($response, Zend_Log::DEBUG, 'oauth.log');
Try your initiate request again, and then check var/log/oauth.log to see what the error is.
Don't even think about doing this on a production system, and ensure you roll back your changes afterwards. You should never modify core files other than for temporary debugging.