I have created a Web service using Netbeans', JEE6 and Jersey - Webservice from Database feature.
So my webservices can be accessed at: http://localhost:8080/SampleWS/listOfItems
The above returns a list of items present in my DataBase. I am using RESTKit on iOS as a client to access this resource.
However, there are two things i would like to do:
1) I would like to restrict access to the above resource only to authenticated users. What is the way to do that?
2) I would also like to restrict only selected out of authorized users to invoke DELETE, PUT and CREATE commands.
Finally, NetBeans allows me to create WS from Database, entities and pattern. Can someone point me to a tutorial for creating a RESTfulwithout using any of the above? In other words, and for example, i would like to map GET, PUT/DELETE methods to mathematical functions like addition, multiplication etc.
You don't mention which app server your deploying to. I assume GlassFish?
I haven't implemented this myself, but I believe Marc Hadleys blog post describes how to configure an application to cover your requirements 1) and 2):
http://weblogs.java.net/blog/mhadley/archive/2008/03/authentication.html
If you're using Spring you might also want to consider using spring-security instead, as described in this answer:
User authentication on a Jersey REST service
Related
I have a "Starter Portal" Power App Portal. I would like to utilize JavaScript and the Web API for querying data. Documentation states
You can use the Web API to perform create, update, and delete operations across all Microsoft Dataverse tables from your portal pages.
Further documentation only lists the CREATE, UPDATE, DELETE operations, and this API being accessible as
[Portal URI]/_api
And I have found how to successfully authenticate using a helper method to get a token for the header:
shell.getTokenDeferred().done(function (token) { ...}
This allows authentication as the user logged into the portal so I believe all relevant Table Permissions, etc. are applied.
But, I would like to retrieve data (HTTP GET). I know this is possible from the Dataverse Web API.. This api is exposed as
[Organization URI]/api/data/v9.1/
Are these really the same API, just exposed a different way for the portal? Is it possible to use the GET endpoints or the second API altogether, authenticated as a Portal Contact user like the previous operations?
It's the same API but permissions are different, you will need to enable the tables you want to access inside the _api endpoint.
You can read more info at this page: https://learn.microsoft.com/en-us/powerapps/maker/portals/read-operations, there is also an XrmToolBox tool to assist you in this operation (but I didn't try it) https://www.xrmtoolbox.com/plugins/PowerPortalWebAPIHelper/
Regarding the Web API calls, I released a new tool to create them (similar to CRM REST Builder) I also added a "Portals" syntax (is in preview) but the generated urls are the same. Link: https://github.com/GuidoPreite/DRB
I have a requirement to build a service endpoint to provide specific Sitecore 8.0 items (containing a given field value in a given branch of the content tree) to requesting mobile app clients. Encapsulating this logic (and perhaps some other calculations, etc) means the out-of-the-box API is not suitable.
I'd like to mimic an existing SOAP service exposed by another CMS, however I'm not above using a modified version of the RESTful itemWebApi if it confers greater code reusability or upgrade-safety.
Based on my research thusfar, it would appear my options are to build a custom handler, a completely separate asmx service (ala this approach), or to build a custom controller (similar to this custom Web API controller method).
Overriding or replacing the default pipeline processors for the itemWebApi does not seem viable, as I don't want to replace/modify the OOB API if I can avoid it.
Has anyone with the same type of requirement for Sitecore 8 found a better approach?
The approach I chose was to create a separate service "router" developed using the adapter pattern to be consumed by our mobile app clients. The router in turn calls the Sitecore ItemWebApi.
This fit my needs the best as it is completely decoupled from the Sitecore application and the client can be modified if necessary without impacting the endpoint.
It would also be worth looking to EntityService within Sitecore.Services.Client in Sitecore 8. Its a Web API based service but has more flexibility over the standard Sitecore Item Web API because you can define your model and the business logic yourself.
I can see you have mention my other blog post on adding a custom Web API controller. Enitity Service is different, it's a framework by Sitecore to achieve a standard way of creating custom web service for Sitecore.
I have written a blog post on EntityService. It has both a Javascript and standard rest based API to communicate with the service too.
http://mikerobbins.co.uk/2015/01/06/entityservice-sitecore-service-client/
Example Application here: https://github.com/sobek1985/EntityServiceDemo
And a few more posts on advanced features in Entity Service: http://mikerobbins.co.uk/category/sitecore/sitecore-service-client/
I need to create register/login functionality in CQ5. There are three ways
1 - The register/login functionality should be prepared as web service hosted on a Java Application Server and then we can consume data from web services.
2 - The functionality should be prepared as web service based on RESTFull that hosted on CQ itself since AEM is developed around the REST principal and REST web services is certainly one which will be supported. So I believe RESTfull web services can be hosted with CQ5.
3 - Why do we need web services? I do not think it requires web services since my application is not going to communicate with other application and it dont want to expose any services to outside world. Why don't we create register/login functionality as we do in normal web application. Can we create a OSGI bundle that invoke databases to store user details for register/login functionality?
I would go for 3rd option but my concern is AEM is not the place to build our business logic to carry out functions that are not related to content rendering.
which option would you choose and why? Kindly share your ideas and thoughts. I am just looking for best solution to develop register/login functionality in CQ.
Thanks
I think i am late to the party but it might help someone. Yes, you can very well create rest webservices in CQ and they work well. So, you can take that approach.
The way to go about implementing login/registration would be how it is done OOTB but OOTB is also bad in the way it implements it so you have to make modifications to overcome that.
1) You need to register and Authentication handler with CQ. If you are looking for a sample there is a form authentication handler source that you can look at.
2) We have integrated out Auth handler with Active Directory (AD). Since AD is supported by default, so it is easy to integrate with Auth Handlers.
3) Next you need to create a user login token for which you can look into TokenUtil class of CQ or if you are looking to develop SSO, you can look into SSO code that is packaged OOTB.
I am working on a salesforce feature, where we are trying to expose a single web Service method in a custom class to a "Partner" so they can generate leads.
The class/method has been created/tested and functions as expects, so we are working on implementation.
I have been poring over all of Salesforce's Web Service documentation and cookbook recipes, but everything I see only talks about using either the Enterprise or Partner WSDL files, which would give them more access then I believe should be required.
If I import the WSDL file that is generated off the class itself, I have access to the methods, but I can't seem to find any way to log in (using their examples as reference).
I have 2 basic questions here.
Do I really need to give full access to my instance to expose a single method?
What is the bare minimum I need to provide?
The WSDL itself is just a definition of the web service and does not control actual access to your org. To get access to your org, a session id must be included in each request to the web service. Session ids are tied to a given user in your org, so you can also control what they can access by giving them their own profile and locking down access to only what they need to get to. The profiles are associated with objects/fields, not the web services themselves, think about what they will need to access in terms of data, because they could always use that same session to access other web services. There are also Apex class-level access controls on the profile, but this doesn't stop them from doing the same data operations through the SOAP APIs, so make sure you have their profile only expose what they need access to and that will be enforced everywhere.
As far as obtaining the session id, it somewhat depends on how you are interfacing with them and what their application is like. In general, the recommended way is to use OAuth (called "Remote Access" in Salesforce Help), which will make it so usernames and passwords don't have to be used in their application, but are rather sent directly to Salesforce by the end user. There are a few different flows to choose from depending on the app and are explained in Help. The REST API doc has a nice intro to using OAuht to get the session id (aka "token" in OAuth). Speaking of REST, you might even consider using the new Apex REST API, which allows you to make similar custom web services from Apex, but with REST interfaces.
The Partner and Enterprise APIs also have a login() method, which is convenient since it is also SOAP-based, but is losing favor because the app has to directly handle the username and password. If you do this option, you would login with either the Partner and Enterprise API, get the session id, and then switch over to your custom web service. So, yes, for this option you would have to consume both your WSDL and either the Partner or Enterprise WSDL, and just ignore the other methods, but again, the methods just being there does not mean they can access them (e.g. if you remove Delete from their profile for a given object type, they would not be able to use the delete() method for it).
What you provide, and what they can do are 2 separate things, if you give them a users credentials, then they can do anything the user can do regardless of which WSDL they use. So you'll want to create a user with restricted permissions that has the bare minimum rights to do what you want.
Once you've got that, it doesn't matter if you give them the enterprise, partner or a custom WSDL.
If you give them the apex class WSDL, then they'll need some way to login, which could be login from the partner WSDL, one of the OAuth2 flows, or a webtab or custom link. (depending on the exact scenario).
Finally, have you seen the web2lead feature, that allows for leads to be created in your salesforce account without needing a WSDL or credentials.
We don't exactly comply with the XML-RPC spec, but the concepts are nearly identical. A client comes in over HTTP/HTTPS with an XML payload. We respond with an XML payload answering the request. This is primarily machine to machine, so no human to type a username/password. Our construct runs within apache tomcat. We would like to authenticate the request and since not every service is available to every client, we need to authorize the request as well. We have both subscription and per use charging models so it is necessary to log everything.
What would you recommend for both server and client?
HTTP BASIC/DIGEST works fine for most machine to machine tasks, and it handled by the server so your API is unaffected.
It doesn't work as well for interactive uses because it's difficult to "log out" the user without closing the browser.
Otherwise you'll most likely need to alter your APIs to include authentication information and have your methods authenticate that within your code.
Or you could use the classic "login", set a cookie, keep a session technique.
But, frankly, for machine to machine work, HTTP BASIC is the easiest.
edit, regarding comments.
HTTP BASIC is simply a protocol used to present the artifacts necessary for authentication, and it works well for machine to machine web services.
HOW IT IS IMPLEMENTED is dependent on you and your application. Using Java, you can use container authentication and that will provide authentication as well as role mapping. The user -> role mapping is handled in either a data file or database. The URLs protected, and what roles are valid for each URL, is managed by web.xml.
If you continue to add different roles to different URLs, then, yes, you'll need to redeploy that application.
However, if you're just adding new users, then you simply update your file or database. And if you're adding new logic, and this new URLs, then you have to redeploy anyway. If you have a ROLE structure with a fine enough granularity, you won't have to be messing with the web.xml until you actually add new methods. For example you could, at the extreme, create a role per method, and assign them individually to users. Most don't need to go that far.
If you don't want to use container authentication, then write a Servlet Filter to implement your vision of mapping user and roles to URLs. You can still use the HTTP BASIC protocol for your clients, even if you implement your own facility.
If you're looking for an overall generic Java security framework, I defer to google -- there are several, I've not used any of them. I've had good luck with container authentication and writing our own.
#Will
I second the HTTP Basic suggestion, and can testify that it integrates fairly well with Spring Security, which I implemented on top of a legacy application that rolled its own DB-based authentication/authorization logic.