Does Apex/Visualforce allow a URL which is stored as string in apex and run it in web browser in background.
Actually, that url is returned from a Docusign RestAPI callout for posting the envelope into "correction" status. The Envelope correction Status is not activated until i manually paste the url (link) in to a web browser and run it.
Does anyone know how to run a url programatically in a web browser through Apex/Visualforce in background ?
(or)
Is there anyway that i could activate the "correction" status of envelope in Docusign other than running the URL in web browser?
As I understand your question(s), the simple answer is NO/YES, but let me break it down:
Run String URL from Apex - Yes - See pagereference
https://www.salesforce.com/us/developer/docs/apexcode/Content/apex_system_pagereference.htm
Can you run a URL in Background - Yes you can use HTTP class
https://www.salesforce.com/us/developer/docs/apexcode/Content/apex_classes_restful_http_http.htm#apex_classes_restful_http_http
Can you run a DocuSign correct URL in Background - NO, the URL you get back requires the Browser for rendering and user UI interaction.
Other Way - YES via the DocuSign REST API you can correct the envelope if it has not been completed or the signer has not completed their signing action. Also I have lab I created to demonstrate this on Amazon if you are interested in a step by step example of DocuSign correct.
https://www.salesforce.com/us/developer/docs/apexcode/Content/apex_classes_restful_http_http.htm#apex_classes_restful_http_http
SAMPLE HTTP PUT via DS REST API below for existing an envelope:
PUT /restapi/v2/accounts/437977/envelopes/ed3be3c1-be06-41c2-c68c-10ddccbd655e/recipients
Host: demo.docusign.net
X-DocuSign-Authentication: {"Username":"yourdsemailorID","Password":"yourpasswordorDSapipassword","IntegratorKey":"yourDSintegratorkey"}
Content-Type: application/json
Accept: application/json
{ "signers": [ { "recipientId": "1", "name": "David W. Grigsby (corrected)", "email": "youremail#yourdomain.com" } ] }
Related
Let me explain the problem really quickly.
I have an addon which is self-distributed. In my manifest.json I have the following bit of code:
"applications": {
"gecko": {
"id": "#my-addon",
"update_url": "https://www.example.com/extension"
}
}
What this allows me to do is have Firefox automatically check this update_url for addon updates every 24 hours, or you can check for updates manually from about:addons page.
Here lies the problem - example.com is a server that I own, and the example.com/extensions route is a special one that only allows access to users which are authenticated. So if I log in to example.com and then go to said URL, my browser (Firefox) would automatically send any stored cookies for that domain in the headers of that request.
However, Firefox does not send any cookies along with the request when it's checking for updates:
If I open the Browser Console, I can see that the request has failed, and if I check my server logs I can see why it has failed - credentials (cookies) are missing.
Why is all of this a problem? It's a problem because I don't want the extensions update manifest to be publicly accessible, I want only authenticated users to be able to access it.
So my question is, how do I get around this problem?
Cheers!
Google released this blog post which says:
If you authorize download requests to the Drive API using the access
token in a query parameter, you will need to migrate your requests to
authenticate using an HTTP header instead. Starting January 1, 2020,
download calls to files.get, revisions.get and files.export endpoints
which authenticate using the access token in the query parameter will
no longer be supported, which means you’ll need to update your
authentication method.
and then says:
For file downloads, redirect to the webContentLink which will instruct
the browser to download the content. If the application wants to
display the file to the user, they can simply redirect to the
alternateLink in v2 or webViewLink in v3.
however if we use webContentLink then we will hit the 100mb virus page mentioned here.
I can see that the migration has been delayed, however sooner or later this will happen, and we want to future-proof the application.
How will we be able to download content without hitting the 100mb virus limit, after this change is implemented?
If you authorize download requests to the Drive API using the access token in a query parameter, you will need to migrate your requests to authenticate using an HTTP header instead.
Example query param:
GET https://www.googleapis.com/drive/v3/files/[FILEID]?access_token=[YOUR_ACCESS_TOKEN] HTTP/1.1
Accept: application/json
Example requests header:
GET https://www.googleapis.com/drive/v3/files/[FILEID] HTTP/1.1
Authorization: Bearer [YOUR_ACCESS_TOKEN]
Accept: application/json
Assuming that you can do the http header option then you should not have any issues with the download as mentioned. The issues with download only come into play if you cant add the authorization header. In which case i think you would need to go with option number two and export the files directly.
We are trying to create an approval workflow using Teams, Flow, and Assembla and are running into a bit of trouble.
We have a few of the pieces successfully setup however we are unable to initiate a POST action from a card in Teams.
In teams we can successfully create a card using the incoming webhook connector with this result.
This is created with the following JSON body from a POST action in Flow
{
"##type": "MessageCard",
"##context": "http://schema.org/extensions",
"summary": "This is the summary property",
"themeColor": "f46b42",
"sections": [
{
"startGroup": true,
"title": "**Pending Review**",
"activityTitle": "Ticket Title",
"activitySubtitle": "Requested by: ",
"facts": [
{ "name": "Date submitted:", "value": "06/27/2017, 2:44 PM" },
{ "name": "Details:",
"value": "This ticket is ready for review." }
]
},
{
"potentialAction": [
{
"##type": "HttpPOST",
"name": "Approve",
"target": "ANOTHER-POST-URL-IS-HERE"
},
{
"##type": "HttpPOST",
"name": "Deny",
"target": "ANOTHER-POST-URL-IS-HERE"
}
]
}
]
}
We have another Flow url as the target for both buttons on the card. To test this url we are able to successfully post via POSTMAN and continue the approval workflow.
When clicking the button on the Team card the Flow at the post url is in no way notified at all. No run on Flow is triggered. In teams a very generic "There was a problem submitting your changes. Try again in a minute." error is displayed.
After researching I ran across the connectors.md file on the Microsoft Teams github page and noticed this lovely part of the documentation
It seems odd to me that right below them mentioning that POST actions may not be supported the documentation goes on in length to show examples of using POST and ActionCard actions in a card on teams.
So my question is this, is there any way to get an HttpPOST action to work from a custom card in Teams to a Microsoft Flow POST URL?
Thanks!
Update:
Upon further testing we have determined that HttpPOST actions
work with just about any post url we can come up with except
Microsoft Flow Request URLs. They are exceptionally long urls so maybe
that has something to do with it?
Here's an example Flow request url.
https://prod-43.westus.logic.azure.com:443/workflows/f86b928acd3d4ecab849f677974f7816/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=ZBxr5GFKQhMp4JXWGmec_L6aqgcaqvCOKUWOf2li-xQ
When running teams in a web browser we are able to see the request
first posts to a api.teams.skype.com url and returns a generic
"ProviderError". Other non-flow urls also do the same but return
success.
This was a head-scratcher for us - as you surmised, this should have worked. The Teams, Flow, and Outlook teams troubleshooted this today and found out what was going on.
The URL you are posting to, https://prod-43.westus.logic.azure.com[...] has an embedded bearer token (the value of the sig parameter in the URL). When you POST to that URL via CURL, Fiddler, Postman, etc. it works because that token is present.
However, when you click on a HttpPOST button in an actionable message, Outlook adds its own JWT token in the HTTP header, meaning that the HTTP POST has both a sig= bearer token in the URL and a JWT token in the HTTP header. Flow detects this and rejects the HTTP POST as invalid (while we don't currently support JWT tokens, we plan to, and treat this case as invalid to maintain forward compatibility).
This use case will work in the future. In the meantime, one workaround to try would be to have the actionable message buttons POST to your endpoints, e.g. https://yoursite.com/accept and https://yoursite.com/deny (validating the JWT as much as you like) and have these endpoints POST to Flow directly without the JWT.
Please let us know if that works.
BTW, the text you found is a documentation bug that has since been fixed:
Sorry for the confusion.
I have never used Jmeter before. I have been trying to use Jmeter to send an HTTP request to Google Vision API - but it's returning a FORBIDDEN (403) error. My request as well as required response is in JSON format.
I have attached below the:
a) HTTP Request
b) Response Error
Other than this, in HTTP Header Manager I have set:
Content-Type: application/json
What is wrong with the attached request?
Request image..
Response error image
According to Authenticating to the Cloud Vision API article you might require to provide OAuth token, it can be done via HTTP Header Manager like:
Name: Authorization
Value: Bearer YOUR_ACCESS_TOKEN
See How to Run Performance Tests on OAuth Secured Apps with JMeter article for more details on interacting with OAuth-protected web applications in JMeter tests.
I am trying to make a script to test REST services using Jmeter.
Till now I was using Chrome’s Advanced REST Client.
My authentication request was GET and it was something like this in Advanced REST:
https://username:password#URL:portnumber
its a GET request
Now when I am using Jmeter. I tried following ways:
I added HTTP Authorization Manager and mentioned Base URL and Username/password inside it.
When I am trying to do a request then its showing me “Unauthorized”
I also tried to login using normal https request but no success.
When accessed manually, a authorization popup window appears and username and password is submitted inside this window.
Please suggest me a way for how to login using Jmeter.
Few suggestions:
Most likely you have mismatch in URL you're trying hit and the one, specified in HTTP Authorization Manager, double check it.
Add View Results Tree listener and make sure that the header like:
Authorization: Basic xxxxxxxxxxxx=
is being sent along with the request and compare it with the one, sent by the real browser.
Try switching "Implementation" of your HTTP Request samplers to HttpClient3.1, the easiest way of doing this is using HTTP Request Defaults
And finally, you can use HTTP Header Manager to send the relevant header, it's name should be Authorization and value Basic and username:password encoded in Base64. There is base64Encode function available via JMeter Plugins.