Is the order of DocuSign statuses for a single envelope guaranteed? I am asking in the context of the Docusign for SalesForce managed package.
For example, given that we have only one Signer/ Recipient, will the Delivered status always be sent before Completed?
Thanks
The order of the statuses should always be guaranteed and the Delivered Status should be sent before the Completed status as you can see in the definition below that the Completed status is reached when the recipients have completed the transaction. On the other hand, the Delivered status is reached when the recipients have viewed the envelope but not necessarily signed it:
Delivered
All recipients have viewed the document(s) in an envelope through the DocuSign signing web site. This is not an email delivery of the documents in an envelope.
Completed
The envelope has been completed by all the recipients.
Source : official documentation
Related
I have a restAPI which allows for users to submit data to be saved in my database. When data is submitted their userID will be grabbed from the request header and added to the document
In my collection (mongoDB) there is the normal _id field and a userID field, which references the user.
My question is in the scenario that a malicious user submits a PUT or DELETE request to a document that does not belong to them what is the best way to handle it.
I pull the prediction from the DB just using the submitted _id, check the userID field against the requesting userID and issue a 403 response if they do not match.
I query the database by both _id and userID, so it would not be found if the document does not belong to the requesting user. I would then issue a 404 response just as if they had submitted an id that does not exist.
Both choices achieve the same goal, which is to prevent a user from editing or deleting a resource that does not belong to them, but which is "better"?
404 is for "not found", which is clearly not the case.
Use 403.
Quoting from Wikipedia:
HTTP 403 is returned when the client is not permitted access to the resource despite providing authentication ...
I would return 403 if user A has permission to view a resource that belongs to user B (as they are already aware of the existence of this resource). Otherwise, I would return 404 for privacy reasons. This is in line with the RFC 9110 standard:
An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
In my shopify store I have setup an order creation webhook. The webhook points to a Cakephp action URL which receives the data from webhook as following:-
$content = file_get_contents ( "php://input" );
After that it is saving this order data to the app database as:-
$orderData =array('order'=>$data['order_number'],'details'=>$content);
$orders = new Order ();
$orders->saveall($orderData);
Now the issue is that for each single order created the webhook is getting invoked multiple times. Although it performs the necessary action in the first attempt, yet Shopify is not able to identify the call success and is getting it invoked again and again until the limit reaches. After the limit is reached the webhook is getting deleted from the store.
My question is that do we need to send any type of status or response to the webhook call after it performs the necessary action. Because it is not very clear from shopify webhook documentation. They state that webhook call success is determined from HTTP status 200. How can I check what is the status returned by a webhook call? How can I make sure that Shopify is informed of webhook success through my app code and it does not invokes further calls to the webhook?
Yes, you need to send a 200 response to Shopify within a short time 5s. Otherwise, Shopify will send a request in a short time.
The official guide suggests that you store the webhook data and process it with a queue, thread, or whatever ways you preferred. After that, you return a 200 response to Shopify immediately.
IMO, if there are many webhook requests sending to you, it's better to separate the webhook receiver from your app server. You can do it with AWS Lambda or docker swarm so that the webhook requests won't break your app server.
Source:
Time limit: enter link description here
Webhooks with AWS Lambda: enter link description here
Just to clarify for others, you have to explicitly return a 2XX HTTP code or it'll retry 19 times over 48 hours, then delete your webhook if it exceeds that.
I noticed that when I send messages from the gmail API and then get an email response to them, the response is never threaded with the original message. Repro steps:
On gmail.com, create a new email draft to someone. Don't send it.
Go to https://developers.google.com/gmail/api/v1/reference/users/drafts/list and log in at the bottom. Enter 'me' for userId and click Execute to get the ID for your draft.
Go to https://developers.google.com/gmail/api/v1/reference/users/drafts/send, log in at the bottom, enter 'me' for userId and fill in the ID from step 2. Click Execute to send the draft.
Have the other person respond to your email.
On gmail.com, the person's response is not threaded with the original email that was sent. However, this works just fine if you send from the gmail UI instead of the API. In examining the headers, the only difference is that the API adds a second 'Received' header. I'm not sure if this is the cause of gmail not threading.
Has anyone else seen this? What is the gmail.com UI different from the API when sending a draft?
It was a bug. Barring issues rolling out the fix, should be resolved by next Weds, July 9th.
Is there a way to send http request (to a specific url address) each time i receive email (Google account), with the content of the email received using Google App Engine?
As per your question, it seems that you already have an Incoming Email Handler in your App Engine application.
If the above is true, then in the Incoming Email Handler, you can parse out the message and if it meets your condition for invoking the http request, then you can definitely do that. You can use the URL Fetch service for the same.
One design decision you might want to do is whether you want to keep all your URL Fetch code inside of the incoming Email Handler or you want that to be handled externally via a Task Queue. In that case, I suggest that you can use the Task Queue to create a task when an incoming email comes in to your handler. Then the Task Queue logic can take care of one or more things, which includes invoking the HTTP Service, as you wanted.
How do I prevent the '....com via 2uix4h7xygsz66weerlq.apphosting.bounces.google.com' from showing up in the header when sending email from AppEngine? I'm sending to myself yet it still shows.
I found this page which says
https://support.google.com/mail/answer/1311182?hl=en-GB&ctx=mail&authuser=1#
I'm a sender and I don't want my recipients to see the "via" link. What can I do?
Gmail checks whether emails are correctly authenticated. If your messages are sent by a bulk mailing vendor or by third-party affiliates, please publish an SPF record that includes the IPs of the vendor or affiliates which send your messages and sign your messages with a DKIM signature that is associated with your domain.
Yet looking at the headers, it shows that SPF and DKIM are already set and passed!
Return-Path: <3OIblUgoJBXcWVif-mZXjibhVdg.XjhXcgjZjidsYZqx.Xjh#2uix4h7xygsz66weerlq.apphosting.bounces.google.com>
Received-SPF: pass (google.com: domain of 3OIblUgoJBXcWVif-mZXjibhVdg.XjhXcgjZjidsYZqx.Xjh#2uix4h7xygsz66weerlq.apphosting.bounces.google.com designates 209.85.212.72 as permitted sender) client-ip=209.85.212.72;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of 3OIblUgoJBXcWVif-mZXjibhVdg.XjhXcgjZjidsYZqx.Xjh#2uix4h7xygsz66weerlq.apphosting.bounces.google.com designates 209.85.212.72 as permitted sender) smtp.mail=3OIblUgoJBXcWVif-mZXjibhVdg.XjhXcgjZjidsYZqx.Xjh#2uix4h7xygsz66weerlq.apphosting.bounces.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=mime-version:reply-to:message-id:date:subject:from:to:content-type;
bh=chRsCD+FjUjL41bfEeXlAef5gWxlIYtGdgQGKtsk5nQ=;
b=g+3WZtFRy1F6d5cRX94eRcKaNk4yg8M1OS/qUDV9ju8El7XIxE5KGsR+6Jo5rOB5ZX
g3U3Gb9KRTOm3FQ7d7X3mVbZUauuZOYzmpijJ65R0Qnc5U0sljIB5IYmKropnxJHIeyi
DOuaL6FFMfrDclpWf1E9o8eXclkAxTdllRTQxjWrc91vucH89dMfs8jCF/KmWUFMECuX
Z69zmxKEnNn0FXZXP5i0FodxfZlb6qn7OSKeE4MVpehBIA7l0bsVv8pLOWQmBWSrQHqr
fD9dlC0r3+hYmYR8lxrR+7mtikt+hOnD3SIV7Vh0+MtZH3rOqKT5uJo262SGbD66Ckgf
yZ3A==
The code is rather mild
Message message = prepareMessage();
Transport.send(message);
Domains that want to reliably send emails should have DKIM and SPF set in their DNS configuration. This is needed to that you email does not get marked as spam.
If you send from #gmail.com, than Google sets this. But if you send mail from you custom domain, then you need to set this on your own.
In your case it seems that you send from custom domain, so google adds a "via" header along with it's own DKIM/SPF records so that this mail has better spam protection.