I am building a backend in feathers. One of the routes in the API spec is:
/people/{pid}/userData:updatePassword
Is there a way to add this custom action to a people or UserData controller ?
Also is there a way to implement one service which have also it subroutes included. For example: I have a /family service. I also have a /family/{fid}/members. Is there a way to include the memberspart in the family service ?
HTTP discourages putting actions into the URL and Feathers enforces this a little more strictly than many other frameworks. A good example why actions that modify data shouldn't be done through a GET request would be a /users/:userid/delete route where e.g. the Google crawler can come in and wipe your entire site.
To create, modify and remove data is what the POST, PATCH, PUT and DELETE HTTP methods and the respective Feathers service methods .create, .patch, .update and .remove are for.
So instead of your suggested /people/{pid}/userData:updatePassword you would do PATCH /people/{pid} with a { "password": "newPassword" } JSON body.
To create a route like /family/{fid}/members you can find more information here, additionally see the FAQ entry on nested routes.
Related
Hi I am new for nopcommerce 3.5. I need to write a restful web service api to third party(for eg mobile) access the service. I know that we can access through Nop.Plugin.Misc.WebServices . I had enable the service from administrator site.
But now is my question. How can i call the web service for eg GetPaymentMethod , product list and etc
And if I want to write my custom web service by using web api. what is step to create? I cant find any documentation about the web service. Please guide me some example
Thanks
If you want a really quick start in writing a web service in NopCommerce, you can follow the MVC architecture and:
Create an Action method inside a Controller that you find appropriate for your purpose. For example, if you want access to a product list, you might create an Action inside CatalogController that follows the logic of the existing ProductList action.
Set up a Route in RouteProvider.cs to point to the Action you created. Based on this route you can deduce the URL of your service.
Do the processing that you need inside the Action. If this Action/service is to be called with parameters (in query string format: param=value¶m2=value2), you can just put these parameters in the Action's header:
public ActionResult QuickService(int param, string param2) { ... and .NET will take care of having them initialized.
Store results in an object (can also be an anonymous object) and at the end of your action, return it as Json: return Json(resultsObject); Again, ASP.NET takes care of the JSON serialization and automatically sets the Content-Type HTTP response header to "application/json".
You can consume the service calling the URL that corresponds to the route of your Action.
If you want users to be able to log in, by using the above method, it gets a little bit trickier. You need the webservice client to be able to accept and send cookies, as well as make appropriate services for Login, Logout, Register,...
However, in this case, you might be better off with a mobile version of the site.
Final note: If you don't want to alter base NopCommerce code, you can apply the steps above to a plugin. The majority of NopCommerce plugins follow the MVC architecture, so you can apply the steps above.
I've been looking into if it's possible to create a web based version of my Chrome Plugin
now that it's relying completely on Trakt.TV's JSON API.
According to angular's documentation, it's possible to intercept HTTP requests at several levels, one is the HTTP Backend itself (mainly used for testing though) and the other is HTTPInterceptor.get
The basic idea is to wrap calls to Trakt.TV's JSONP api through http://json2jsonp.com/ and have them returned transparently to get around cross site scripting restrictions. This would not only be very useful for my own project, but for a lot of other people daeling with the same issues too (therefore i'll release the module after it's done, but I want to do it properly)
The basics should be simple:
Hook the $http.get request at the right level
Overwrite the original request made
Cancel an optional other request already set up
Hook it through $http.jsonp(http://json2jsonp.com/)
Return the original promise's success/fail when done
Questions:
Has anyone built anything like this yet? (Github searches revealed nothing)
Would you suggest using the HTTPBackend or the HTTPInterceptor?
why can't you just use the jsonp helper function?
httpBakend is a mockup service to fake a backend server is not used on live code. http interceptors would do what you want you just need to attach the callback function name to your request if the url contains what ever name you want to filter and then in the response interceptor you have to pass response to the callback function so the json to be evaluated. be aware that interceptors will inspect every request makde by angular which is not very eficien, unless you are only doing calls to the tv service.
like i said before a better approach is to use $http.jsonp function
https://docs.angularjs.org/api/ng/service/$http#jsonp
a word about interceptors they need to be defined as services and then be passed to HttpProvider during your apps configuration.
I understand that deleting data with an http GET is a security hole. Is it also the case that calling delete from a link in general is a bad idea? I'm referring specifically to an asp.net mvc actionlink that specifies the http method as a POST.
#Ajax.ActionLink("Delete",
"DeleteNote", new { noteid = Model.noteid },
new AjaxOptions
{
Confirm = "Delete?",
HttpMethod = "POST",
OnSuccess = "postmessage('note_Deleted_" + Model.noteid + "')"
})
Using HTTP GET is not a security hole, but could be considered bad design for a RESTful API. The convention is to use HTTP DELETE for deletion of resources. The security hole is if your API does not support any authentication/authorization, whether it is a GET, DELETE, POST or PUT. Then anybody with a web browser or tool like Fiddler could manipulate data they should not have access to. Take a look at this article that describes how to use a customized Authorize attribute to secure a Web API.
You can still use a link to invoke your API but do not use a direct link that defines an href to the URL for delete. Instead define your anchor like this with an id.
Delete
Then define a click event that calls a Javascript function that makes a secure ajax call to your API as described in the previously mentioned article.
$('aDeleteNote').click(DeleteNoteFunc);
If you want to use Razor to specify the noteid used to identify what to delete then you can put it in a hidden field our a Javascript variable that the DeleteNoteFunc has access to.
What you're touching on here is a vulnerability called Cross Site Request Forgery.
A quick example of this would be as follows.
You have a GET link on your website, e.g. "www.example.com/notes/delete/232"
A user is logged into your website with permissions to delete note 232.
The user receives an email from the attacker that entices them to visit the attacker's website.
The user visits the website in the email, but one of the image tags is defined as follows: "<img src="http://www.example.com/notes/delete/232" width="0" height="0" />"
This causes the browser to make a HTTP request to your website, sending the correct authentication cookies which will result in the note being deleted without the user's knowledge.
Now this is not a vulnerability in the GET itself, but it is one of the reasons why methods such as GET should not be used to make changes on the server.
Yes you are correct you should use POST for this. POST would still be vulnerable to an attack similar to the above but the attacker would either need to create a standard HTML form to POST the data, or would have to create the POST via AJAX. If you pass the HTTP header "X-Requested-With: XMLHttpRequest" and check this in your server method this will help prevent this attack as this header cannot be added to a cross domain request.
If you want to further secure this then you should implement the Synchroniser Token Pattern which will validate a token as part of the POST request to ensure the request came from your own site.
I don't know if I'd describe deleting data from a GET request as necessarily a security hole (provided your application implements proper security), but it's often not a great idea as you know.
If you have delete links, you should definitely put nofollow on them, but I don't think that links which delete data are inherently bad. Even if you have no link in your markup, you still end up making an http request to a url that will delete something, either through a form submission or ajax.
I am trying to build my application's admin UI using sling's userManager REST interface, but I would like to customize the json rendering. For example, I would like the response of "Get group" to include the members only if the requestor is a member.
I started by adding libs/sling/group/json.esp but I don't understand how I can get hold of the default response and customize it. Even if I had to query and form the json from scratch, where can I find information about APIs available to get this data from JCR/Sling?
I found that I could use ResourceTraversor to dump the resource object in json form but using new Packages.org.apache.sling.servlets.get.impl.helpers.ResourceTraversor(-1, 10000, resource, true) in the esp throws up an error
There are a few things to note here.
First, you should avoid putting your code under the libs directory. Your app code should live under the apps directory. When attempting to resolve a servlet for a URI, Sling will check apps before it checks libs so if you need to completely override functionality delivered with Sling, you would place your code in apps.
Second, what is (probably, depending on how you have things setup) happening when you request http://localhost:8080/system/userManager/group/administrators.tidy.1.json is the request is being handled by Sling's default GET servlet, because it finds no other script or servlet which is applicable. For research purposes it might be worth looking at the code for the default get servlet, org.apache.sling.servlets.get.impl.DefaultGetServlet, to see what it's using to render JSON. If you need to handle the rendering of a user group in a manner different than what the default GET servlet is doing, then you would need to create a servlet which is listening for requests for resources of type sling/group. It would probably be ideal to create a servlet for this purpose and register it with OSGI. http://sling.apache.org/site/servlets.html provides the various properties you would need to set to ensure the servlet resolver finds your servlet. Your servlet then would handle the request and as such would have direct and easy access to the requested resource.
Third, the particular need you specified is that you do not want the group members to render unless the requesting user is a member of the group requested. This is more of an access control issue than a rendering issue. Sling and Jackrabbit, out of the box, make as few assumptions as possible concerning how you might want your application to be setup. That being the case, you need to establish the access controls that are applicable for your particular use case. The wiki post on Access Control in the Jackrabbit wiki ( http://wiki.apache.org/jackrabbit/AccessControl ) goes into this to an extent.
Using directions from Paul Michelotti's answer, I researched further and found a suitable solution to my problem.
Sling accepts request filters (javax.servlet.Filter) through SCR annotations like the one below
#SlingFilter(scope = SlingFilterScope.REQUEST, order = Integer.MIN_VALUE)
Every request is passed down to the filter before it is processed by the servlet. Using the resourceType, I was able to distinguish requests to group.1.json and group/mygroup.1.json. Since the filter also has access to the current user, I was able to decide to deny the request if it did not abide by my security model and return a 404 status code.
Please refer to this page for details on filters. You can also check out the sample project urlfilter for directions on usage.
In regards to this Haacked blog, I'm hesitant to implement the proposed anti-JSON GET hijacking solutions since
The recommended solutions to mitigating JSON hijacking involve non-REST-full JSON POSTs to GET data
The alternate solution (object wrapping) causes problems with 3rd party controls I don't have source-code access to.
I can't find a community-vetted implementation that implements the Alternative Solution (listed below) on how to compose the security token, or securely deliver it within the webpage. I also won't claim to be enough of an expert to roll my own implementation.
Referrer headers can't be relied upon
Background
This blog describes a CSRF issue regarding JSON Hijacking and recommends using JSON POSTs to GET data. Since using a HTTP POST to GET data isn't very REST-full, I'd looking for a more RESTfull solution that enables REST actions per session, or per page.
Another mitigation technique is to wrap JSON data in an object as described here. I'm afraid this may just delay the issue, until another technique is found.
Alternative Implementation
To me, it seems natural to extend the use ASP.NET MVC's AntiForgeryToken with jQuery HTTP GETs for my JSON.
For example if I GET some sensitive data, according to the Haacked link above, the following code is vulnerable:
$.getJSON('[url]', { [parameters] }, function(json) {
// callback function code
});
I agree that it isn't RESTfull to GET data using the recommended POST workaround. My thought is to send a validation token in the URL. That way the CSRF-style attacker won't know the complete URL. Cached, or not cached, they won't be able to get the data.
Below are two examples of how a JSON GET query could be done. I'm not sure what implementation is most effective, but may guess that the first one is safer from errant proxies caching this data, thus making it vulnerable to an attacker.
http://localhost:54607/Home/AdminBalances/ENCODEDTOKEN-TOKEN-HERE
or
http://localhost:54607/Home/AdminBalances?ENCODEDTOKEN-TOKEN-HERE
... which might as well be MVC3's AntiForgeryToken, or a variant (see swt) thereof. This token would be set as an inline value on whatever URL format is chosen above.
Sample questions that prevent me from rolling my own solution
What URL format (above) would you use to validate the JSON GET (slash, questionmark, etc) Will a proxy respond to http://localhost:54607/Home/AdminBalances with http://localhost:54607/Home/AdminBalances?ENCODEDTOKEN-TOKEN-HERE data?
How would you deliver that encoded token to the webpage? Inline, or as a page variable?
How would you compose the token? Built in AntiforgeryToken, or by some other means?
The AntiForgeryToken uses a cookie. Would a backing cookie be used/needed in this case? HTTP Only? What about SSL in conjunction with HTTP Only?
How would you set your cache headers? Anything special for the Google Web Accelerator (for example)
What are the implications of just making the JSON request SSL?
Should the returned JSON array still be wrapped in an object just for safety's sake?
How will this solution interop with Microsoft's proposed templating and databinding features
The questions above are the reasons I'm not forging ahead and doing this myself. Not to mention there likely more questions I haven't thought of, and yet are a risk.
The Asp.net MVC AntiForgeryToken won't work through HTTP GET, because it relies on cookies which rely on HTTP POST (it uses the "Double Submit Cookies" technique described in the OWASP XSRF Prevention Cheat Sheet). You can also additionally protect the cookies sent to the client by setting the as httponly, so they cannot be spoofed via a script.
In this document you can find various techniques that can be used to prevent XSRF. It seems the you described would fall into the Approach 1. But we have a problem on how to retrieve the session on the server when using Ajax HTTP GET request since the cookies are not sent with the request. So you would also have to add a session identifier to you action's URL (aka. cookieless sessions, which are easier to hijack). So in order to perform an attack the attacker would only need to know the correct URL to perform the GET request.
Perhaps a good solution would be to store the session data using some key from the users SSL certificate (for example the certs thumb-print). This way only the owner of the SSL certificate could access his session. This way you don't need to use cookies and you don't need to send session identifiers via query string parameters.
Anyway, you will need to roll out your own XSRF protection if you don't want to use HTTP POST in Asp.net MVC.
I came to this problem and the solution was not so trivial however there is a fantastic blog to get you started this can be used with get and post ajax.
http://johan.driessen.se/posts/Updated-Anti-XSRF-Validation-for-ASP.NET-MVC-4-RC
If you place the following in the global name space all your post/gets can take advantage having an anti forgery token and you don't have to modify your ajax calls. Create an input element in a common page.
<form id="__AjaxAntiForgeryForm" action="#" method="post">#Html.AntiForgeryToken()</form>
The following javascript will read the anti forgery tokken and add it to the request header.
// Wire up the global jQuery ajaxSend event handler.
$(document).ajaxSend(namespace.ajax.globalSendHandler);
// <summary>
// Global handler for all ajax send events.
// </summary>
namespace.ajax.globalSendHandler = function (event, xhr, ajaxOptions) {
// Add the anti forgery token
xhr.setRequestHeader('__RequestVerificationToken', $("#__AjaxAntiForgeryForm input[name=__RequestVerificationToken]").val());
};
I think it is legitimate to use AntiforgeryToken (AFT) within an ajax http GET request provided that it is embedded in a form that already provides the AFT and associated cookie. The ajax handler can then do the validate on the server just how it would in a normal form post.