Liferay WebService for access to Custom Fields - web-services

I recently researched on an Android application which uses Liferay 6.1. However, I am stuck with ability to update the custom field's value using Liferay API.
I hooked the custom fields into users_admin portlet user/details.jsp and made public view accessible:
<liferay-ui:custom-attribute
className="com.liferay.portal.model.User"
classPK="<%= (selUser != null) ? selUser.getUserId() : 0 %>"
editable="<%= true %>"
label="<%= true %>"
name="Course"
/>
Also hooked into login portlet create_account.jsp:
<div>
<liferay-ui:custom-attribute
className="<%= User.class.getName() %>"
classPK="<%= 0 %>"
editable="<%= true %>"
label="<%= true %>"
name="Course"
/>
</div>
Therefore, I need a custom webservice to access these values via http client to post/get value. Any idea where to start looking?
I've tried several webservice tutorials but none offers specific solution on accessing expando value of the custom fields.
Here's roughly what I'm stuck with:
Mobile app -> Liferay API -> Update custom field info
Mobile app -> Liferay API -> Retrieve custom field info

As you've already mentioned the magic word "Expando", you already know where to look: Check Expando*Service in the docs (note: Webservices will end in *Service, while the 'local' services will end in *LocalService.
Using Expandos feels a bit like barebones work with tables: There's an ExpandoTable, ExpandoColumn and ExpandoValue. If you're ok with a sample that uses the LocalService (sorry, no webservice), you might want to check this little extension to Liferay that makes use of the Expando attributes, particularly in PodcastingUtil.getEnclosure(...).
The codebase should be small enough to get an idea of the basic handling of Expandos, otherwise let me know of open questions. Without looking it up, I expect the remote interface being quite similar to the local interface that I'm using in that project.

Related

Testing HelloSign API embedded signature

Hello I am using the HelloSign API, looking to test the embedded signing feature. How am I able to test the embedded document to sign on my test site? I am using the nodejs SDK along with AngularJS. Thank you in advance.
Here's the general walkthrough for embedded signing, which walks you through the server side and client side steps: https://app.hellosign.com/api/embeddedSigningWalkthrough
Here's an FAQ on testing locally: https://faq.hellosign.com/hc/en-us/articles/217048987-What-tools-can-I-use-to-test-the-API-and-callbacks-locally-
For greater detail, please write into apisupport#hellosign.com.
-First thing is create an account with Hellosign
Next thing is creating your API KEY from your registered account.
Create an API App with your registered hellosign account (This is important because during the setup it will ask for the URL where the Iframe will be created.)
Now to use it simply include this script (<script type="text/javascript" src="https://s3.amazonaws.com/cdn.hellosign.com/public/js/hellosign-embedded.LATEST.min.js"></script>).
And then finally do this in your client side component file
HelloSign.init("CLIENT_ID");
HelloSign.open({
url: "SIGN_URL",
allowCancel: true,
messageListener: function(eventData) {
// do something
}
});
And Voila..!! It will work.

How to open JSF page using JAX-RS web service?

I would like other web application (in .net or any other) to call my JAX-RS web service to set and open my JSF page with some passed values.
E.g.
Another web application just pass the userId and a token to open an entry page.
User will complete the entry and service will return the uniqueId for created entry.
I am confused in how I can set JSF context parameters and open that JSF page using JAX-RS. Can anyone give idea about how to set value of JSF session scoped managed bean using web service?
First of all, this question indicates a misunderstanding of purpose of "REST web services" in general. The question concretely asks to perform two rather unusual tasks with a REST web service:
Manipulating the HTTP session associated with the request.
Redirecting to a HTML page managed by a stateful MVC framework as response.
Both squarely contradict the stateless nature of REST. Those tasks aren't supposed to be performed by a REST web service. Moreover, REST web services are primarily intented to be used by programmatic clients (e.g. JavaScript or Java code), not by webbrowsers which consume HTML pages. You normally don't enter the URL of a REST webservice in browser's address bar in order to see a HTML page. You normally enter the URL of a HTML page in browser's address bar. That HTML page can in turn be produced by a HTML form based MVC framework such as JSF.
In your specific case, after the programmatic client has retrieved the unique
ID from the REST web service, then the programmatic client should in turn all by itself fire a new request to the JSF web application. E.g. as follows in Java based client (below example assumes it's a plain servlet, but it can be anything else as you said yourself):
String uniqueId = restClient.getUniqueId(userId, token);
String url = "http://example.com/context/login.xhtml?uniqueId=" + URLEncoder.encode(uniqueId, "UTF-8");
response.sendRedirect(url);
In the target JSF web application, just use <f:viewParam>/<f:viewAction> the usual way in order to grab the unique ID and perform business actions based on that. E.g. as below in login.xhtml:
<f:metadata>
<f:viewParam name="uniqueId" value="#{authenticator.uniqueId}" />
<f:viewAction action="#{authenticator.check}" />
</f:metadata>
#ManagedBean
#RequestScoped
public class Authenticator {
private String uniqueId;
#EJB
private UserService service;
public String check() {
FacesContext context = FacesContext.getCurrentInstance();
User user = service.authenticate(uniqueId);
if (user != null) {
context.getExternalContext().getSessionMap().put("user", user);
return "/somehome.xhtml?faces-redirect=true";
}
else {
context.addMessage(null, new FacesMessage("Invalid token"));
return null; // Or some error page.
}
}
// Getter/setter.
}
Perhaps the REST webservice could for convenience even return the full URL including the unique ID so that the client doesn't need to worry about the target URL.
String uniqueIdURL = restClient.getUniqueIdURL(userId, token);
response.sendRedirect(uniqueIdURL);
On the other hand, there's a reasonable chance that you just misunderstood the functional requirement and you can just directly process the user ID and token in the JSF web application, the more likely if it runs at the same server as the REST web service and also uses HTTPS. Just add an extra <f:viewParam> and do the same business service logic as the JAX-RS resource in the <f:viewAction> method.
<f:metadata>
<f:viewParam name="userId" value="#{authenticator.userId}" />
<f:viewParam name="token" value="#{authenticator.token}" />
<f:viewAction action="#{authenticator.check}" />
</f:metadata>
See also:
What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?
How to implement JAX-RS RESTful service in JSF framework
Try this in your code,
return new Viewable("/index", "FOO");
Or,
RequestDispatcher rd = request.getRequestDispatcher("{url}");
rd.forward(request, response);
Or,
return Response.status(myCode).entity(new Viewable("/index", "FOO")).build();
try these example working in using jersey,
#GET
public Response get() {
URI uri=new URI("http://nohost/context");
Viewable viewable=new Viewable("/index", "FOO");
return Response.ok(viewable).build();
}
to return something different use this approach:
#GET
public Response get() {
int statusCode=204;
Viewable myViewable=new Viewable("/index","FOO");
return Response.status(statusCode).entity(myViewable).build();
}
Hope that helpe

Is there any other way to block an iframe other than 'x-frame-options' 'sameorigin'

I work for a company that has a rails app and generally we want to block most of our controller actions from being embedded in an iframe, however some of our clients are asking for certain pages to be embeddable in iframes.
Rails 4 sets 'x-frame-options' to 'sameorigin' by default so my solution was to delete the 'x-frame-options' header when the http referer matched the url given to us by the client. The reason I deleted the x-frame-options instead of setting it to 'allow-from [url]' is because 'allow-from' is not supported by some relatively
My boss doesn't think this is the most secure solution though because the x-frame-options isn't supported by some older browsers.
Is there some way of detecting if a controller action is being embedded in an iframe that I could detect using a built in rails method?
You can use javascript and see if the window matches the toplevel window
var inIframe = window !== window.top; // true if in iframe false otherwise

How do I authenticate and consume an external api with backbone?

I'm trying to create a very basic little backbone app that displays stats from my company's Harvest account. They have a REST API which authenticates via Basic Auth or oAuth. I seem to be faced with two problems here:
Authentication
Cross-origin requests
So I've started with setting the url for my collection to the respective url:
var Projects = Backbone.Collection.extend({
url: 'https://mycompany.harvestapp.com/projects',
});
And I've tried using this basic auth plugin but I can't tell if that part is working because I'm still getting Access-Control-Allow-Origin errors.
What's the best way to go about this?
This other StackOverflow question is similar and has more details that you should take a look at.
But the general idea is this, if you don't have access to the remote server (which I presume you do not with Harvest) then you need to perform the cross-site requests from your own server that you do control, most likely the one you are deploying this backbone app on. That means writing some server-side code (PHP, Node, etc.) to perform the requests (perfectly legal from server side) and then having your client (Backbone app) request from these scripts.
Here is a brief/pseudo-example with php:
request.php
<?php
echo file_get_contents('https://mycompany.harvestapp.com/projects');
?>
projects.js
var Projects = Backbone.Collection.extend({
url: 'request.php',
});

CSRF handling with Adobe Flash Application using Django backend

I'm building a flash game that uses Django as a backend.
I currently have an api endpoint set up using django-tastypie, which the flash app can call to receive JSON data for populating the application.
I understand using simple django views, and templating system, one is able to simply include a csrf_token in a webpage with the aid of the middleware.
My problem now is trying to post data back to the server without using csrf_exempt, and the flash application ideally, can be run without inserting params tags. Hopefully, a standalone swf file that'll work as it is.
How would one get a csrf_token into the flash app so it can post data back to the server without security concerns?
If the csrf_token way is not possible, are there any other ways to post data securely?
I have searched many avenues leading to similar questions, but many are unanswered.
Maybe I'm missing something here as I'm engrossed in my perspective. I hope someone can enlighten me on better ways to do it.
Thanks in advance.
It sounds like you may have two problems:
How do I actually send the CSRF token with my POST requests from Flash?
Django also accepts CSRF tokens via the header X-CRSFToken. See the docs here.
You can append headers to your request like so:
var req:URLRequest=new URLRequest();
req.url="http://somesite.com";
var header:URLRequestHeader=new URLRequestHeader("X-CSRFToken","foobar");
req.requestHeaders.push(header);
URLRequests docs are here.
How do I get the CSRF token into my Flash file in the first place?!
(Option A) Because CSRF tokens are generated on a per request basis (e.g., with templating a traditional HTML form, on a GET request) the simplest thing to do is to pass the CSRF token to the Flash file via a templated parameter. Something like: <param name="csrf_token" value="{{ my_csrf_token }}" />
(Option B) It sounds like you don't want to do the parameter thing, so your final option is to build a custom Django view which has the sole functionality of delivering a CSRFToken to your Flash file. So the Flow would be your Flash file loads, your Flash makes a GET request to http://mysite.com/csrf_token/ which simply returns a valid CSRF token, and then you can use that token to do your POST. (Note you will need to do a GET request for each POST request).