I need a bit of help understanding what this means:
https://wordpress.org/plugins/json-api/other_notes/#Method:-create_post
Required argument
nonce - available from the get_nonce method (call with vars controller=posts >and method=create_post)
How should I create that nonce?
I'm trying:
wp_nonce_field( 'posts', 'create_post' );
Note that you don't have to use the wordpress nonce functionality directly, instead use Json Api's given method in the post controller.
You may try the solution of bbottema
First you need a nonce (Number used ONCE), which is a temporary key you'll use to be able to invoke the API with:
http://yourblog.com/?json=core.get_nonce&controller=posts&method=create_post&callback=?
This gives you a nonce number (be sure to use &callback=? as it marks the content as jsonp, or you'll get a similar -but invalid- nonce).
Then use this nonce to create a post:
http://yourblog.com/?json=posts.create_post&nonce='+nonce+'&title='+title+'&content='+content+'&status=publish (or draft, or leave it out altogether)
Make sure you have the 'posts' controller enabled in your wordpress plugin JSon API settings. Check this manual for what JSon data structures you can expect back from these calls.
Now, here's the tricky part: you need to be already logged into the wordpress site, because with this JSon API, you can't log in. I haven't figured that part out yet, so I'm still looking for a good solution myself. I tried manually posting and also width ajax but with limited results considering I'm missing a WordPress test cookie in my headers (at least this is the main difference I see when logging in from the site and doing it manually)
JSON API USER Does not work, it will only work if you are logged in to the website with an account of ADMIN ROLE!.. otherwise it won't create valid nonce
Related
I've been told by support to write here, so:
I'm using the "useradd" endpoint to add users for my app. However, after the user is successfully created, the token I'm getting does not actually work.
Weirdly enough I can see it in the dashboard, but shortly after I try using it on the client JS code, it disappears from there.
Seems like some sort of weird bug to me, but not sure. 🤷♂️
Also: When I either regenerate the token on the dashboard by hand before trying it, or add it after it disappears, that one would work.
Post your code and how you are generating token. Whatever unique string you use for generating token MUST also be used when you call setAppName
Read tutorials here https://mesibo.com/documentation/tutorials/get-started/first-app/
Turns out if was because the backend normalises whatever app id I use.
So "GoneWithTheWind" becomes "gonewiththewind", and hence if you use "GoneWithTheWind" in the JS setAppName call, it won't work.
(And your token will disappear for some reason as well.)
Leading- and trailing whitespaces are stripped as well.
Also, numeric "app id" is fine, just make sure that it's used as a string in the JS code, so for example: setAppName("4567").
I did create a simple testcase in JMeter.
Open a form and all it's content (css, images etc) :
GET /
GET /css/site.css
GET /favicon.ico
GET /fonts/specific-fonts.woff
GET /images/banner.png
Wait a little...
Post the values
POST /
Receive the "Thank You" page.
- GET /thanks
In the response on the first GET is a hidden input field which contains a token. This token needs to be included in the POST as well.
Now I use the "Regular Expression Extractor" of JMeter to get the token from the response. So far, so good.
Then, after retreiving all the other contents I create the POST message, using the variable name in the RegExp-Extractor in the value field of the token parameter.
But... when executing the testcase it fills in the default value given and not the actual value of the token.
So... first step in debugging this issue was to add a dummy-HTTP-GET request directly after I get the token. In this GET request I also add the token parameter with the token variable as value, but now I can easily check the parameter by looking at the access-log on my webserver.
In this case... the URL looks promising. It contains the actual token value in the GET, but it still uses the default value in the POST.
Second step in debugging was to use the "Debug Sampler" and the "View Results Tree".
By moving the Debug Sampler between the different steps I found out the value of the token-variable is back to the default value after I receive the CSS.
So... now the big question is...
How can I make JMeter to remember my variable value until the end of my test-script ?
JMeter doesn't "forget" variables. However variables scope is limited to the current Thread Group. You can convert JMeter variable to JMeter Property which have "global" scope by i.e. using Beanshell Post Processor with the following code:
props.put("myVar", vars.get("myVar"));
Or by using __setProperty() function. See How to Use Variables in Different Thread Groups guide for details.
As you found it your problem comes from a misunderstanding of scoping rules in jmeter.
https://jmeter.apache.org/usermanual/test_plan.html#scoping_rules
In your case, just put the post processor of the request that will give you the response containing the child node.
Also I think you don't need to share this token with other threads so don't use properties as proposed in the alternate answer.
I'm trying to finalise on a restful url structure for the wishlist section of a site I'm working on. It's a pretty simple model, a user can have many wishlists and each wishlist can contain many products.
Currently I have the obvious CRUD URLs to manipulate the wishlist itself :
GET account/wishlists.json
GET account/wishlists/{id}.json
POST account/wishlists.json?name=My%20Wishlist
POST account/wishlists/{id}.json?name=My%20New%20Name
DELETE account/wishlists/{id}.json
However, I don't think I know how to structure the URLs that would add/remove a product to a wishlist :(
Here are my current choices :
1) Have the product to add as part of the URL and use the HTTP verb to define my action
POST account/wishlist/{id}/product/{product_id}.json
DELETE account/wishlist/{id}/product/{product_id}.json
or
2) Have the action as part of the URL and the product id as part of the payload
POST account/wishlist/{id}/add.json?product_id={product_id}
POST account/wishlist/{id}/remove.json?product_id={product_id}
(1) is clean and, as far as I can tell it's pretty RESTful but doesn't allow things like adding multiple products easily etc.
I'm also a bit concerned about using the DELETE verb - I'm not deleting the product or the wishlist, I'm just removing one from the other.
(2) is more explicit but veers away from REST - I wouldn't be just referring to the resource in the url, I would be referring to an operation on that resource :(
Any advice on which of the above would be more correct would be very helpful! (If there's a third option that's better than mine, feel free to correct me!)
(1) is the only valid approach for REST, using HTTP verbs for actions.
(2) encodes method names into the URI which is more like RPC and of course not RESTful.
Concerning your shortcomings about the first approach:
The DELETE verb is fine, because your resource is the item inside in the wishlist, not the item itself.
You can support batch requests. For instance, you might want to allow to POST a list of items to a wishlist resource resulting in mutliple adds.
PS: Prefer HTTP content negotiation (Accept and Content-Type headers) over representation formats encoded in the URI.
I think your first option is more in line with the REST philosophy. If you want to manipulate multiple products, you could pass the ids as a list in the body, instead of using a query parameter.
As for the delete part, given that you are deleting a subresource of wishlist, I think the intention is clear (i.e. remove the connection from the wishlist to the product). If you wanted to globally remove a product, the URL should be something like
DELETE /products/{id}
As noted by other responses, the first option is clearly the RESTful approach. The approach to deleting products from the wishlist looks fine - after all you would be doing a DELETE on product/{product_id} to remove the product itself.
For adding products, you might wish to consider a POST to account/wishlist/{id}/product/ the body of which could contain a list of product IDs.
Here's a nice article on how to think about REST URLs
I'm working on a REST server. I have an order RESOURCE.
From my understanding the PUT verb should create a new order based on the URL. My question is: How can this work if the resource is new and you don't know the ID of the new order?
I know the debate about POST vs PUT, but I'm quoting the w3 specs for PUT http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
"If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI"
In RESTful APIs, PUT is typically used to update a resource or create one if it doesn't exist at the specified URL (i.e. the client provides the id). If the server generates the id, RESTful APIs typically use a POST to create new resources. In the latter scenario, the generated id/url is usually returned or specified in a redirect.
Example: POST /orders/
According to W3C Both PUT and POST can be used for update and/or create.
The basic difference between them is how the server handles the Request-URI. PUT URI identifies the entity and the server should't try to map it to another URL, while POST URI can be a handler for that content. Examples:
It's OK to POST a new order to /order, but not a PUT. You can update order 1 with a PUT or POST to /order/1.
To put it simply POST is for creating and PUT is for updating. If you don't have an ID for an object because it isn't created yet, you should be using a POST. If an object DOES exist and you just don't have the ID for it, you're going to have to search for it using a GET of some kind.
The thing to remember is Idempotence. A PUT (and GET for that matter) is idempotent. Basically meaning, you can hit the same URL over and over and it shouldn't make a difference the 2nd or 3rd time (It edits the data once, and calling it again it doesn't make that change again). However a POST is not idempotent. Meaning, you hit the same URL 3 or 4 times in a row and it's going to keep changing data (creating more and more objects). This is why a browser will warn you if you click back to a POST url.
You say, "don't know the ID of the new order" therefore the following is not true "URI is capable of being defined as a new resource by the requesting user agent", therefore PUT is not appropriate in your scenario.
Where is the confusion? I am of course assuming the Id would be part of the URL.
document.aspnetForm.action = "https://www.paypal.com/cgi-bin/webscr";
I use master page and paypal payment page but giving error "document.aspnetform is not defined"
I can't tell from your question whether you are doing this on the client using JavaScript or on the server in C#. I guess the former as you are using document all lower case. Either way check your capitalisation - Javascript is case sensitive so you may need document.AspNetForm or something similar as your identifier. Just make sure it matches up to whatever the title of the form is in the source code.