My requirement is that send an email to some recipient with text body using POSTMAN Native app,
I used the below endpoint with requested data,
Base URL: https://www.googleapis.com/gmail/v1/users/userId/messages/send
Headers :Authorization:Bearer
Request Method :POST
Request body :{"raw";"to:user1mail#gmail.com","subject":"Test_Mail"}
Clicking Send button
But getting error response code 400,required recipient address
Please help me in this to send an email using POSTMAN,and I've tried with upload end point too -https://www.googleapis.com/upload/gmail/v1/users/user1email#gmail.com/messages/send
Thanks in advance,looking for help guys
Came across your question trying to figure this out myself today.
Request body : {"raw";"to:user1mail#gmail.com","subject":"Test_Mail"}
The raw param should be a complete email message that's base64-encoded.
i.e.: {"raw": "VG86IHVzZXIxbWFpbEBnbWFpbC5jb20KU3ViamVjdDogVGVzdF9NYWls"}
400 error means bad request, which could mean there are missing or wrong parameters. Check the Users.messages.send
Path parameters
userId string The user's email address. The special value me can be
used to indicate the authenticated user.
Required query parameters
uploadType string The type of upload request to the /upload URI.
Acceptable values are:
media - Simple upload. Upload the media only, without any metadata.
multipart - Multipart upload. Upload both the media and its metadata, in a single request.
resumable - Resumable upload. Upload the file in a resumable fashion, using a series of at least two requests where the first
request includes the metadata.
Related
I am using AWS Cloudfront to serve static html and images from a private s3 bucket. I need an authentication layer and have a requirement to use Microsoft SSO. To trigger the authentication check, I have a Lambda function connected to a Cloudfront Viewer Request.
From what I understand, I need to return the Request in a callback method when I want to get past the viewer request (after authentication). My issue is that the Microsoft SSO redirect's to the Cloudfront URL using an HTTP POST. If I return the request, Cloudfront attempts to POST to an S3 (or sends a MethodNotAllowed when I disable POST). I need this to be a GET request, but do not know how I can change it. According to the docs, the HTTP of the request object is read only.
I have tried redirecting to the Cloudfront URL when posting or serving a simple HTML that links to the html I want, but these both result in the Viewer Request being called again.
Has anyone handled a similar situation?
You should be able to return a redirect, but set the status code to 303 instead of one of the other 3xx codes. This is See Other which results in the browser following the redirect but using GET on the second request. There is no way to trick CloudFront into believing the method changed -- a redirect is required.
I am trying to send a PATCH request to the Vimeo API in order to start uploading the video based on the documentation.
I am using Postman. I've read {upload.upload_link} field, set the required headers but I still can't hit the API.
Does anyone know what could be the problem?
Try making that PATCH request again, but without the Authorization or Host headers, as they are not required for that upload endpoint:
https://developer.vimeo.com/api/upload/videos#resumable-approach-step-2
I am using s3-bucket to store app config data for multi tenant application. I need tenant info saved in public file(.json) in s3-bucket before client is logged in to the application. For example, app config data might be client logo and some custom title/sub-title for each tenant and etc. I am trying to fetch file content based on sub-domain.
So, I need to fetch the client data, while rendering the login component itself. I am using aws-sdk tool in client side, but am facing 'missing credentials` error.
I am not getting, How to achieve this??
thanks and regards
SHASHIDHAR N K
The AWS SDK for Javascript uses the S3 rest API in such a way that it requires a GET request to be authorized. This is because it uses request parameters to override response header values and for these the rest API documentation for GET says:
Note - You must sign the request, either using an Authorization header or a pre-signed URL, when using these parameters. They cannot be used with an unsigned (anonymous) request.
However, you don't need to use S3 to get a public file, you can make a standard http request using XMLHttpRequest or suchlike.
We're implementing WSO2-AM to handle access to some internal APIs from our Moodle LMS we wish to expose to the internet.
I am configuring the access to this LMS via WSO2 but I've run into an issue I can't resolve.
I realise WSO2 documentation is extensive, but I'be not been able to actually find a specific instance of this configuration.
Background: Moodle itself has implemented its APIs in a very non-standard manner. They call them REST, but they are not truly restful. Some of the parameters, such as a users token, are passed in the URL query string rather than using headers in the body of the query itself.
To start with, I have two APIs configured in WSO2, one to request a user token from Moodle (Moodle requires this to permit access to the API for a specific user) and another to get the users enrolled course list.
The first request to get the user token from Moodle via WSO2 proceeds as expected. I pass in the username/password/service parameters via the header as you would expect (so that they are encrypted over HTTPS) to WSO2, which it pushes to Moodle, as a POST. The response from Moodle via WSO2 is as expected, a JSON payload containing a token which my client then parses to use in subsequent requests.
The next request is then calling a more useful service in Moodle, to get a users enrolled courses. There are two issues noted here which I'm unsure how to resolve.
The problems: Moodle expects GET or POST parameters for the call to the web-service. When I'm using GET, which is handy for testing, the parameters passed from the client to WSO2 are either wrong (in the case of the 'userid') or missing (in the case of the wstoken field, which is in the post body).
In API publisher I have the API in WSO2 configured for POST with a URL pattern of {version}/courses/{userid}
The API definition is configured as below:
API Endpoint configuration is:
URL: http://(moodleurl)/webservice/rest/server.php?wstoken={uri.var.wstoken}&wsfunction=core_enrol_get_users_courses&moodlewsrestformat=json&userid={uri.var.userid}
GET URL as received by Apache hosting Moodle is:
xx.xx.xx.xx - - [09/Aug/2016:10:36:03 +0930] "POST /webservice/rest/server.php?wstoken=&wsfunction=core_enrol_get_users_courses&moodlewsrestformat=json&userid=6/6 HTTP/1.1" 200 270
So, the two issues are the missing 'wstoken' parameter (which is in the post body provided to WSO2, and the 'userid' being doubled up with a slash between the items.
I have run the client via a proxy and the data appears to be sent correctly to WSO2:
So I'm wondering what I can do about these problems:
Is there a different URL parameter I can use to correctly include a posted body param in the URL out to the service API address?
Is there some specific configuration problem I've made that's causing the userid parameter to break in this manner?
The posted parameters from the client do appear to be included in the post to Moodle by WSO2; so it is likely they can be stripped from the URL and simply included in the post body to Moodle by WSO2, meaning that it's likely only the issue with the userid parameter that needs to be resolved to allow this to work - unfortunately I'm not sure how to place a proxy between WSO2 and Moodle itself to validate the parameters that are posted to the API, short of using Wireshark.
The 'userid' being doubled up with a slash between the items because the URI template of the API's resource is automatically appended to the end of the HTTP endpoint at runtime. For an example in your case you defined the endpoint url as:
http://(moodleurl)/webservice/rest/server.php?wstoken={uri.var.wstoken}&wsfunction=core_enrol_get_users_courses&moodlewsrestformat=json&userid={uri.var.userid}
Then url pattern (/{userid}) appends to the endpoint url by default. To overcome this issue you can use the following mediator setting to remove the URL postfix from the backend endpoint:
<property name="REST_URL_POSTFIX" scope="axis2" action="remove"/>
For more on this please refer the link given in [1].
You can read the variables in the resources (urls) during mediation runtime using property values with the "uri.var." prefix. For example, in your case HTTP endpoint gets the wstoken and userid as the uri variables. But wstoken contains in the body section of the request. Therefore you cannot add it by introducing wstoken={uri.var.wstoken} as a query paramter to the endpoint. One way that you can overcome this issue is by defining wstoken as a query parameter by changing the parameter Type to query. The other way is you can define it in the header of the incoming request.
[1]. https://docs.wso2.com/display/AM190/Map+the+Parameters+of+your+Backend+URLs+with+the+API+Publisher+URLs
I am trying to use the YUI uploader to upload files to Django view.
However, I am getting a 403 error in CsrfViewMiddleware. I have determined that the problem is due to the flash uploader (that the YUI uploader uses) not sending the CSRF cookie in the file upload request.
The YUI uploader's uploadAll() function allows additional data to be sent with the upload request in object form. Since the CSRF cookie can be easily retrieved, I am trying to add the cookie to the request via the uploadAll() function, but I am not entirely sure as to what format to send it in so that CsrfViewMiddleware finds the cookie where it expects it. This does not work:
var cookie = YAHOO.util.Cookie.get('csrftoken');
uploader.uploadAll(url, 'POST', { csrfmiddlewaretoken: cookie });
Any insight would be greatly appreciated!
Unfortunately, because of Flash player limitations, the YUI Uploader can't insert the cookie into the header of the request, which is where the backend expects it to be. The only thing you can do, which is what that additional argument up there does, is to add POST variables to the request. However, that means that you need additional server logic to extract them as POST variables and them compare them to the cookie record -- it won't work by default.
If you are unable to modify the server-side code, you won't be able to authenticate the requests sent from the Uploader :(.