X11 connection rejected because of wrong authentication

Remote window forwarding for different user

When I try the remote window forwarding from the default user I was able to successfully forward the window. But when I try this in a different user (oracle) this failed with the below error.

[oracle@oracle-rac-setup-node1 wso2]$ xterm
X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).

This seems to be an issue with the cookie but I tried adding the cookie but didn't work so this will provide you an alternative to fix this issue.

1. Login as the super user

2. Copy the Xauthority file of the working user to the other user.

[wso2@oracle-rac-setup-node1 ~]$ sudo -i
[root@oracle-rac-setup-node1 ~]# cp /home/wso2/.Xauthority /home/oracle/.Xauthority

Login to the oracle user and try xterm to verify if the window forwarding works.

[wso2@oracle-rac-setup-node1 ~]$ xterm 

Sharing Subscribers' Application and Subscriptions with Other Subscribers + WSO2 APIM

Hi All,

It is really easy to share your subscriptions within your team or organization.  Please follow the below steps which shows how to configure and use.

STEPS
1.  Go to the api-manager.xml file and Uncomment the <GroupingExtractor> element.
  path - wso2am-1.10.0/repository/conf/api-manager.xml
2. Start the server.
3. If you dont have any API's created. Create and publish an API from the APIM publisher
4. Login to the API Store and go to the signup page. Fill the user details and click more details add an organization name

5. login using that and user and create application and subscribe
6. sign-out from that user and create a new user with the same organization name.  login from that user you can get the first users applications and subscriptions.

If you have any issues feel free to drop a comment.
Have Fun !!!

Retry when Call Mediator fails in In-Sequence WSO2 ESB

Hi All,
This blog post is to show how you could retry when the there is an issue in the in-sequence.

Flow
when the proxy is invoked it will hit the in-sequence(foo) and if there is an issue, onError sequence will be called(retryError).
In the bellow retryError sequence it will check if the error is occurred from login request failure, then it will retry (call back) the foo .
I have specified the retry count as 2 and have added a tread sleep between retries.

How to configure
1. Add this foo sequence as a seperate sequence and use in the proxy service In-Sequence
 Add an onError option to the sequence
e.g -

<sequence name="foo" onError="retryError" xmlns="http://ws.apache.org/ns/synapse">
    <log>
        <property name="Test" value="Inside the in sequence"/>
    </log>
    <call blocking="true">
        <endpoint>
            <address uri="http://localhost:9000/services/SimpleStockQuoteService"/>
        </endpoint>
    </call>
</sequence>

2. Create a new sequence retryError and the bellow code

<?xml version="1.0" encoding="UTF-8"?>
<sequence name="retryError" xmlns="http://ws.apache.org/ns/synapse">
    <filter xmlns:ns="http://org.apache.synapse/xsd"
        xmlns:ns3="http://org.apache.synapse/xsd" xpath="get-property('retry_count')">
        <then>
            <property expression="number(get-property('retry_count'))+1"
                name="retry_count" scope="default"/>
            <filter xpath="get-property('retry_count') > 2">
                <then>
                    <log/>
                    <drop/>
                </then>
                <else>
                    <script language="js"><![CDATA[java.lang.Thread.sleep(5000);]]></script>
                    <clone continueParent="true" sequential="false">
                        <target sequence="foo"/>
                    </clone>
                </else>
            </filter>
        </then>
        <else>
            <script language="js"><![CDATA[java.lang.Thread.sleep(5000);]]></script>
            <property name="retry_count" scope="default" type="STRING" value="1"/>
            <clone continueParent="true" sequential="false">
                <target sequence="foo"/>
            </clone>
        </else>
    </filter>
</sequence>

 If you have an easy way to do this feel free to comment

Have Fun !!!!

Transforming a Json Request In WSO2 API Cloud

Hi All,

If you require to transform an incoming Json request to a Json request  of a different format (Add extra values). You can simply do it by changing the default mediation flow.
This post is to show how you could archive that in a simple and easy steps.

Payload sent from user to the backend

  "tutorials": {
        "id": "wso2",
        "topic": "REST Service",
        "description": "This is REST Service Example by WSO2."
    }

Modified payload sent to backend - (Add the username of the user to the payload data )

{
  "data": {
    "tutorials": {
      "id": "wso2",
      "topic": "REST Service",
      "description": "This is REST Service Example by WSO2."
    }
  },
  "user": "vinurid.wso2.com@testuser"
}

All you have to do is write a custom sequence that modify the payload using PayloadFactory Mediator.
If you want to know more details about the mediator can follow this WSO2 Documentation - https://docs.wso2.com/display/ESB490/PayloadFactory+Mediator

This is a sample sequence that you can use to do the above Payload transformation. You have to save the bellow sequence to an xml file and add to the in-sequence in the API.

<sequence xmlns="http://ws.apache.org/ns/synapse" name="CustomerSequence">
         <payloadFactory media-type="json">
            <format>{"data":$1, "user":"$2"}</format>
            <args>
               <arg evaluator="json" expression="json-eval($)"/>
            <arg expression="$ctx:api.ut.userId"/>
            </args>
         </payloadFactory>
</sequence>


You could follow the bellow video on step by step guidance on how to do this in WSO2 Cloud.
Content in the video
1. Creating an API in WSO2 Cloud.
2. Change the mediation flow in the API in-sequence
3. Show the sequence that added to the in-sequence
4. publish the API
5. Subscribe to the newly created API in WSO2 API Cloud
6. Invoke the API. (Video shows the payload which user sent to the backend)
7. Shows the output for the request
8. Shows the in-coming request in the backend logs. (Request that sent to the backend from the WSO2 API Cloud)

Enabling APIM - BPS Workflow Integration In a Cluster + WSO2

Hi All,

This Post show how you could configure WSO2 APIM workflows in a cluster.
Please Note this post is based on the bellow documentation, more like a summary of what you really should do.
https://docs.wso2.com/display/AM1100/Configuring+Workflows+in+a+Cluster
https://docs.wso2.com/display/AM1100/Adding+an+Application+Creation+Workflow

WSO2 Product Versions -
wso2bps 3.5.1
wso2am 1.10.0

Setup Information

1. 2 bps nodes clustered with a LB

• <bps1 IP> hostname /IP of the bps node 1
• <bps2 IP> hostname /IP of the bps node 2
• <bpsLB IP> hostname /IP of the bps LB

2. 2 APIM store nodes clustered  with a LB

Important Notes -

• Assuming that the admin role is not changed.
• All bps and apim nodes are running in a separate servers and started using offset 0
• Configuring the Admin Dashboard in store side.
• Please note both nodes should have the correct server certificates and the client-truststore should know both sides as well

Setting up APIM store node

1. Change the workFlowServerURL in the admin dashboard configuration. wso2am-1.10.0/repository/deployment/server/jaggeryapps/admin-dashboard/site/conf/site.json

"workFlowServerURL": "https://<bpsLB>:9443/services/",

2. Changed the WorkflowCallbackService.xml to point the store node.

Since we are configuring the admin-dashboard of the store side, keeping it as  localhost:9443

/wso2am-1.10.0/repository/deployment/server/synapse-configs/default/proxy-services/WorkflowCallbackService.xml

3. Login to the API Store management console and change the WorkFlowExtensions callbackURL and serviceEndpoint in the registry.

/_system/governance/apimgt/applicationdata/workflow-extensions.xml

E.g - comment the simple workflow executor and enable WS Workflow Executor

<ApplicationCreation executor="org.wso2.carbon.apimgt.impl.workflow.ApplicationCreationWSWorkflowExecutor">         <Property name="serviceEndpoint"> http://<bpsLB IP>:9763/services/ApplicationApprovalWorkFlowProcess/  </Property>         <Property name="username">userName</Property>         <Property name="password">Password</Property>         <Property name="callbackURL">https://<storeLB IP>:8243/services/WorkflowCallbackService</Property>     </ApplicationCreation>

Setting Up BPS Node

1. <BPS_HOME>/repository/conf/humantask.xml file and <BPS_HOME>/repository/conf/b4p-coordination-config.xml file and set the TaskCoordinationEnabled property to true.

<TaskCoordinationEnabled>true</TaskCoordinationEnabled>

2. Copy the following from the <APIM_HOME>/business-processes/epr folder to the <BPS_HOME>/repository/conf/epr folder. If the <BPS_HOME>/repository/conf/epr folder does not exist, please create it.

• In the *CallbackService.epr file change the Address to <storeLB ip> and  also change the username and password
• In the *Service.epr change the  Address to store node ip or localhost and also change the username and password

3. Unzip the <APIM_HOME>/business-processes/user-signup/BPEL/*  (Similar to all the other workflows)

• Change the address port to 9443 in the ApprovalTask wsdl file e.g - UserApprovalTask.wsdl
• In the CallbackService WSDL point the address elements to <storeLB IP>

4. Zip back the files and upload it into the BPS.
5. Unzip the <APIM_HOME>/business-processes/<workflow name>/HumanTask fie.

• Change the port to 9763 in ApprovalTask WSDL

6. Zip back the files and upload it into the BPS Human Task.

Create an Application In store side and login to the admin dashboard to check if workflows working properly.

Have Fun !!! 
 

Gadgets Wont display for the IP address ERROR {org.apache.shindig.gadgets.render.DefaultServiceFetcher} + WSO2 Dashboard

Hi All,
I got this error accessing the DAS Dashboard (Portal) from the IP address instead of localhost.

ERROR {org.apache.shindig.gadgets.render.DefaultServiceFetcher} -  Services methods from the https://IP:9443/shindig/rpc endpoint could not be fetched. The following error occurred: javax.net.ssl.SSLException: hostname in certificate didn't match: <IP> != <localhost>. {org.apache.shindig.gadgets.render.DefaultServiceFetcher}
TID: [-1] [] [2016-06-10 12:07:50,257]  INFO {org.apache.shindig.gadgets.http.BasicHttpFetcher} -  The following exception occurred when fetching https://IP:9443/portal/store/carbon.super/gadget/Message_Table/index.xml: 11 ms elapsed. {org.apache.shindig.gadgets.http.BasicHttpFetcher}
TID: [-1] [] [2016-06-10 12:07:50,259]  INFO {org.apache.shindig.gadgets.http.BasicHttpFetcher} -   {org.apache.shindig.gadgets.http.BasicHttpFetcher}
javax.net.ssl.SSLException: hostname in certificate didn't match: <IP> != <localhost>
        at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:238)
        at org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
        at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:159)
        at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:140)
        at org.apache.http.conn.ssl.SSLSocketFactory.verifyHostname(SSLSocketFactory.java:561)
        at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:536)
        at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:403)
        at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
        at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144)
        at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:131)
        at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
        at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
        at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:115)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
        at org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:359)
        at org.apache.shindig.gadgets.http.DefaultRequestPipeline.fetchResponse(DefaultRequestPipeline.java:191)
        at org.apache.shindig.gadgets.http.DefaultRequestPipeline.execute(DefaultRequestPipeline.java:135)
        at org.apache.shindig.gadgets.AbstractSpecFactory.fetchFromNetwork(AbstractSpecFactory.java:134)
        at org.apache.shindig.gadgets.AbstractSpecFactory.getSpec(AbstractSpecFactory.java:94)
        at org.apache.shindig.gadgets.DefaultGadgetSpecFactory.getGadgetSpec(DefaultGadgetSpecFactory.java:75)
        at org.apache.shindig.gadgets.process.Processor.process(Processor.java:104)
        at org.apache.shindig.gadgets.servlet.GadgetsHandlerService.getMetadata(GadgetsHandlerService.java:210)
        at org.apache.shindig.gadgets.servlet.GadgetsHandler$5.call(GadgetsHandler.java:307)
        at org.apache.shindig.gadgets.servlet.GadgetsHandler$5.call(GadgetsHandler.java:304)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

If you are also facing the same issue,  All you have to do is add a self sign certificate for the server DAS is running.
You could use the bellow article on creating the certificate.
http://wso2.com/library/knowledge-base/2011/08/adding-ca-certificate-authority-signed-certificate-wso2-products/

Not Retrieving Pending Tasks. Check BPS Connectivity + WSO2 APIM 1.10

Hi All,
I got this issue when configuring the APIM workflow support.  Because of this issue APIM admin dashboard cannot retrieve any of the pending tasks which needed to be approve.

WARN {JAGGERY.site.blocks.user.login.ajax.login:jag}- Not Retrieving Pending Tasks. Check BPS Connectivity {JAGGERY.site.blocks.user.login.ajax.login:jag}

WSO2 Versions - 
API Manager 1.10
BPS 3.5.1

Please find the Bellow steps to Identify the correct issue (debug) and fix.

- This issue can mainly occur due to an incorrect bps path given for the workFlowServerURL in the Admin Dashboard.
Verify the workFlowServerURL in the site.json file.

 <APIM HOME>/repository/deployment/server/jaggeryapps/admin-dashboard/site/conf/site.json 

- If your issue is still exists, this can be occur due to a connection timeout or a certificate issues. Easiest way to verify the issue is by putting a log to the login.jag

<APIM HOME>/repository/deployment/server/jaggeryapps/admin-dashboard/modules/user/login.jag

grep the code and find the WARN message "Not Retrieving Pending Tasks" 
Add the bellow mention error log to the code and test again. You will get the full stack trace and it will be easy to identify the main issue.

} catch(e) {
    log.error(e);
    log.warn("Not Retrieving Pending Tasks. Check BPS Connectivity");
}