I went to \simple_salesforce and changed a line in api.py by hand from
DEFAULT_API_VERSION = '42.0'
to
DEFAULT_API_VERSION = '51.0'
But it feels incorrect to do it like this. Is there some other way?
There's bit of text in readme in "additional features".
SalesforceLogin, which takes in a username, password, security token,
optional version and optional domain
(...)
SFType class, which is
used internally by the getattr() method in the Salesforce() class
and represents a specific SObject type. SFType requires object_name
(i.e. Contact), session_id (an authentication ID), sf_instance
(hostname of your Salesforce instance), and an optional sf_version
So looks like you can pass sf_version to SalesforceLogin() call and it'll be respected. Or version to Salesforce(). Check the files and experiment? Maybe even make a pull request in simple's Git repo so they update the default. 42 was over 3 years ago. It's perfectly fine to use newer API to see more tables, get some performance boost, bugfixes.
Related
I have a simple API that return Something for a given ID and it must be used without any kind of authentication, the URL should be permanent and yet I want to avoid as much as possible it to be botted.
The Url is something like this:
https://url/{SomeId}/doSomething
The problem is that this is very predicable and a bot could easily try all the ID and get everything associated to it.
I'm looking for a way to make the URL non predictable like for example:
https://url/{SomeId}/doSomething?Key=SomeVeryLongCryptographicKey
In this way except if you run a supercalculator you shouldn't be able to deduce all the URLs
I know that there is probably a lot of ways to do that, like using a DB which I want to avoid.
I guess I'm looking for a kind a JWT associated to the ID without expiration but maybe there is better solution.
Edit: to give a better example i'm looking to do a bit like did Zoom for permanent invitation Links. They had predictable room Ids and they added a password making it unpredictable lie so:
https://us05web.zoom.us/j/132465789?pwd=SUxIU0pLankyhTRtWmlGbFlNZ21Ndz08
What would be the best/light/"secure" way to achieve that ?
Also I'm using .Net if there is a library doing that, it would be great.
I think your idea of using a JWT makes the most sense. Better to use something standard from a cryptographic point of view, and the JSON format allows for encoding whatever you need to provide to the receiving endpoint (user names, entity names, entity IDs, other things).
There are standard Microsoft libraries for building and validating JWTs, but I prefer the library Jwt.Net (https://www.nuget.org/packages/JWT). It lets you do something like this quite easily:
var token = JwtBuilder()
.WithAlgorithm(new RS256Algorithm(publicKey,privateKey))
.AddClaim("uri", String.Format("https://example.com/api/{0}/{1}", entityName, entityId))
.Encode();
Just add whatever claims you like, and the JWT will then contain what you want to transfer (I've used an example of the URI that you want to give to the entity) and a signature with your private key. You could even just give a URL like https://example.com/from_token/eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ1cmkiOiJodHRwczovL2V4YW1wbGUuY29tL2FwaS90ZXN0RW50aXR5LzEyMzQifQ.K2P4wSF6g1Kt-IHMzlklWTV09_MIkoiNHQztSIYOohmOWe7aBfFSQLIKSbdTECj9XPjNNG_AjH9fdjFglkPuYfr2G9rtl2eh5vTjwdM-Uc0X6RkBu0Z2j7KyMKjkaI3zfkIwhtL1mH873xEBtNOGOW18fuBpgnm8zhMAj1oD3PlDW8-fYBrfLb6VK97DGh_DyxapbksgUeHst7cAGg3Nz97InDPtYcWDi6lDuVQsj3t4iaJBRL8IM785Q8xjlHHhzdfcX3xU4IhflyNHHXxP56_8ahNNMOZKWdwgbTSIxEEB98b3naY3XknC-ea7Nc1y4_5fszrYdy3LaQWV43jpaA
and have the handler decode the entity name and ID you want to retrieve directly from the URI while verifying the signature. Decoding with the library is just as easy:
var json = JwtBuilder.Create()
.WithAlgorithm(new RS256Algorithm(_key))
.MustVerifySignature()
.Decode(token);
I am trying to retrieve a value from a HTTP web service call in sharepoint designer. This should be simple. the Rest query is simple, and always returns only a single value:
https://Site.sharepoint.com/sites/aSiteName/_api/web/lists/getByTitle('MyListTitle')/items/?$select=Title&$top=1
In the Sharepoint Designer workflow, I'm setting the required Accept and Content-type header to the value of "application/json;odata=verbose
I am unable to get the value of the "Title" field that is returned by the call.
when I execute the REST query in the browser, I get the following data returned:
{"d":{"results":[{"__metadata":{"id":"af9697fe-9340-4bb5-9c75-e43e1fe20d30","uri":"https://site.sharepoint.com/sites/aSiteName/_api/Web/Lists(guid'6228d484-4250-455c-904d-6b7096fee573')/Items(5)","etag":"\"1\"","type":"SP.Data.MyListName"},"Title":"John Doe"}]}}
I've tried dozens of variations of the dictionary 'query', but they always return blank.
I'm using the 'get an item from a dictionary' action in SP Designer, using item name or path values like:
d/results(0)/Title
d/Title
d/results/Title
and literally dozens of other variations - but it always returns blank.
I'm writing the raw response from the webRequest to the list for debugging, and it shows the value like this:
{"odata.metadata":"https:\/\/site.sharepoint.com\/sites\/aSiteName\/_api\/$metadata#SP.ListData.MyListTitle&$select=Title","value":[{"odata.type":"SP.Data.MyListTitle","odata.id":"616ed0ed-ef1d-405b-8ea5-2682d9662b0a","odata.etag":"\"1\"","odata.editLink":"Web\/Lists(guid'6228d484-4250-455c-904d-6b7096fee573')\/Items(5)","Title":"John Doe"}]}
I must be doing something simple that is wrong?
Using "d/results(0)/Title" is right. Check the steps in article below to create a workflow.
CALLING THE SHAREPOINT 2013 REST API FROM A SHAREPOINT DESIGNER WORKFLOW
It working fine in my test workflow.
I faced the exact same issue. In my case the reason was that in the API call, the header was not set properly.
As you would have noticed many times, that if you type the variables inline when creating the "Call Http Web service" action, those might not get set properly. The surest way is to open the properties and set from there. In my case when i opened the properties i found that RequestHeaders was not set. Once i set it from there, i got the desired results.
Hope this helps to someone in future, this question being unanswered till now!!
tried dump those json called from sharepoint workflow into a list. Sometimes you'll get a different format than when you called that from browser. I experienced this issue when calling API projectserver (project online). When I called it using servistate (chrome extension) it returns d/results, but when I dump the value into the list I got value and yet I used same request header value.
I was ecstatic when I got a simple webhook event listener working with GitHub push events on my Azure site, but I realize now I'm not seeing the branch name or id in the json payload (example here https://developer.github.com/v3/activity/events/types/#pushevent)
I thought maybe "tree_id" would be it, but it doesn't seem to be. I couldn't find any info about this in GitHubs's doc. Maybe I need to take one of the id's from the event and make another api call to get the branch? The reason for this is I want to be able to link GitHub push events with my app portfolio, which has branches defined. So, the push events are a way to see code change activity on my different apps -- and knowing the branch is therefore important.
I wrote to GitHub support, and they told me that the branch name is part of the "ref" element in the root of the json payload. When parsing from a JToken object called jsonBody, the C# looks like this
var branchName = jsonBody["ref"].ToString().Split('/').Last();
For example in "refs/heads/master", the branch name is "master"
You need to pay closer look on WEBHOOK response mainly. Here is the trick for JSONPATH ( at-least what I did with my jenkins job):
first read your webhook whole response with character "$". You can catch it is some variable like:
$webhookres='$'
echo $webhookres
Once you have response printed, copy it and paste here: https://jsonpath.com/
Now create your pattern. For example if you want branch name (if event is push):
$.ref
Once you have the branch name( it will have extra string with /), simply trim the unwanted part using awk or cut (linux commands).
You are not limited to this only. All you need to work on pattern and you can make use of this approach for getting other values as well like, author, git repo url etc. and then these can be used in your automation further.
even if you are using any other platform like Azure, JSONPATH concept will be same. because as suggested in accepted answer, "jsonBody["ref"]", it is equivalent to $.ref, as altogether you have to identify the PATTERN ( as here PATTERN is 'ref')
I am currently programming a REST service and a website that mostly uses this REST service.
Model:
public class User {
private String realname;
private String username;
private String emailAddress;
private String password;
private Role role;
..
}
View:
One form to update
realname
email address
username
Another form to update the role
And a third form to change the password
.
Focussing on the first view, which pattern would be a good practice?
PUT /user/{userId}
imho not because the form contains only partial data (not role, not password). So it cannot send a whole user object.
PATCH /user/{userId}
may be ok. Is a good way to implement it like:
1) read current user entity
2)
if(source.getRealname() != null) // Check if field was set (partial update)
dest.setRealname(source.getRealname());
.. for all available fields
3) save dest
POST /user/{userId}/generalInformation
as summary for realname, email, username
.
Thank you!
One problem with this approach is that user cannot nullify optional fields since code is not applying the value if (input is empty and value) is null.
This might be ok for password or other required entity field but for example if you have an optional Note field then the user cannot "clean" the field.
Also, if you are using a plain FORM you cannot use PATCH method, only GET or POST.
If you are using Ajax you might be interested in JSON Merge Patch (easier) and/or JavaScript Object Notation (JSON) Patch (most complete); for an overview of the problems that one can find in partial updates and in using PATCH see also this page.
A point is that a form can only send empty or filled value, while a JSON object property can have three states: value (update), null (set null) and no-property (ignore).
An implementation I used with success is ZJSONPATCH
Focussing on the first view, which pattern would be a good practice?
My suggestion starts from a simple idea: how would you do this as web pages in HTML?
You probably start from a page that offers a view of the user, with hyperlinks like "Update profile", "Update role", "Change password". Clicking on update profile would load an html form, maybe with a bunch of default values already filled in. The operator would make changes, then submit the form, which would send a message to an endpoint that knows how to decode the message body and update the model.
The first two steps are "safe" -- the operator isn't proposing any changes. In the last step, the operator is proposing a change, so safe methods would not be appropriate.
HTML, as a hypermedia format, is limited to two methods (GET, POST), so we might see the browser do something like
GET /user/:id
GET /forms/updateGeneralInformation?:id
POST /updates/generalInformation/:id
There are lots of different spellings you can use, depending on how to prefer to organize your resources. The browser doesn't care, because it's just following links.
You have that same flexibility in your API. The first trick in the kit should always be "can I solve this with a new resource?".
Ian S Robinson observed: specialization and innovation depend on an open set. If you restrict yourself to a closed vocabulary of HTTP methods, then the open set you need to innovate needs to lie elsewhere: the RESTful approach is to use an open set of resources.
Update of a profile really does sound like an operation that should be idempotent, so you'd like to use PUT if you can. Is there anything wrong with:
GET /user/:id/generalInformation
PUT /user/:id/generalInformation
It's a write, it's idempotent, it's a complete replacement of the generalInformation resource, so the HTTP spec is happy.
Yes, changing the current representation of multiple resources with a single request is valid HTTP. In fact, this is one of the approaches described by RFC 7231
Partial content updates are possible by targeting a separately identified resource with state that overlaps a portion of the larger resource
If you don't like supporting multiple views of a resource and supporting PUT on each, you can apply the same heuristic ("add more resources") by introducing a command queue to handle changes to the underlying model.
GET /user/:id/generalInformation
PUT /changeRequests/:uuid
Up to you whether you want to represent all change requests as entries in the same collection, or having specialized collections of change requests for subsets of operations. Tomato, tomahto.
I'm currently working on ng-admin.
I'm having a problem retrieving user data from my REST API (connected to a MongoDB) and displaying it.
I have identified the problem as the following:
When I enter http://localhost:3000/users into my browser, I get a list of all users in my database.
When I enter http://localhost:3000/users?_page=1&_perPage=30&_sortDir=DESC&_sortField=id,
I get [] as a result.
I am quite new to this, I used both my browser and the POSTMAN Chrome extension to test this and get the same result.
http://localhost:3000/users_end=30&_order=DESC&_sort=id&_start=0
This (/users_end) is a different request than /users.
It should be:
http://localhost:3000/users?end=30&_order=DESC&_sort=id&_start=0
Or, by looking at the other parameters:
http://localhost:3000/users?_end=30&_order=DESC&_sort=id&_start=0
with end or _end being the first parameter (mark the ?).
Update (it is ? and before the _, I have edited.):
If adding parameters to the request returns an empty list, try adding only one at a time to narrow down the problem (there's probably an error in the usage of those parameters - are you sure you need those underscores?).
Your REST API must have a way to handle pagination, sorting, and filtering. But ng-admin cannot determine exactly how, because REST is a style and not a standard. So ng-admin makes assumptions about how your API does that by default, that's why it adds these _end and _sort query parameters.
In order to transform these parameters into those that your API understands, you'll have to add an interceptor. This is all thoroughly explained in the ng-admin documentation: http://ng-admin-book.marmelab.com/doc/API-mapping.html