Syndesis: When transfering integration between two syndesis instances: Unable to decrypt key:accessToken

Created on 10 May 2018  路  17Comments  路  Source: syndesisio/syndesis

This is a...


[ ] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ x ] Bug report  
[ ] Documentation issue or request

The problem


I'm unable to transfer integration from one syndesis instance to another. The connections (twitter and salesforce in my case) used by the integration use the "basic connection configuration" I don't use the "OAuth Application Management".
After I updated both connections (Orange triangle "Configuration required"), I tried to publish the integration. The server log provides following error:

2018-05-10 07:52:42.744 ERROR [-,,,] 1 --- [tion Controller] i.s.s.c.integration.online.BaseHandler   : Integration [twitter-salesforce]: [ERROR] Activation failure

java.lang.IllegalArgumentException: Unable to decrypt key:accessToken
    at io.syndesis.integration.project.generator.ProjectGeneratorHelper.mandatoryDecrypt(ProjectGeneratorHelper.java:133) ~[integration-project-generator-1.3.5.fuse-000002-redhat-1.jar!/:1.3.5.fuse-000002-redhat-1]
    at io.syndesis.integration.project.generator.ProjectGenerator.addDecryptedKeyProperty(ProjectGenerator.java:223) ~[integration-project-generator-1.3.5.fuse-000002-redhat-1.jar!/:1.3.5.fuse-000002-redhat-1]
    at io.syndesis.integration.project.generator.ProjectGenerator.generateApplicationProperties(ProjectGenerator.java:151) ~[integration-project-generator-1.3.5.fuse-000002-redhat-1.jar!/:1.3.5.fuse-000002-redhat-1]
    at io.syndesis.server.controller.integration.online.PublishHandler.createDeploymentData(PublishHandler.java:131) ~[server-controller-1.3.5.fuse-000002-redhat-1.jar!/:1.3.5.fuse-000002-redhat-1]
    at io.syndesis.server.controller.integration.online.PublishHandler.execute(PublishHandler.java:100) ~[server-controller-1.3.5.fuse-000002-redhat-1.jar!/:1.3.5.fuse-000002-redhat-1]
    at io.syndesis.server.controller.StateChangeHandler.execute(StateChangeHandler.java:33) [server-controller-1.3.5.fuse-000002-redhat-1.jar!/:1.3.5.fuse-000002-redhat-1]
    at io.syndesis.server.controller.integration.IntegrationController.lambda$callStateChangeHandler$11(IntegrationController.java:196) [server-controller-1.3.5.fuse-000002-redhat-1.jar!/:1.3.5.fuse-000002-redhat-1]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[na:1.8.0_171]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[na:1.8.0_171]
    at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_171]

2018-05-10 07:52:42.744 INFO [-,,,] 1 --- [tion Controller] i.s.s.c.i.IntegrationController : Integration i-LC7vFY2P96ad_t7Pzytz : Setting status to Pending (Unable to decrypt key:accessToken)

Expected behavior


The integration should get published after user updates the connections.

Request and Response Data


Attached the exported integration (created on CR1):
twitter_salesforce-export.zip

Server log:
server_log.txt

Tasks involved / Steps to Reproduce

  1. Start two syndesis instances (or you can simply use the attached integration)
  2. Create integration TW->SF on one instance, export it
  3. Import to second instance, update the connections
  4. Publish integration
  5. observe errors in server log, the integration will stay in "Publishing" state indefinitely
cabug exdocs grouintegration prip1 sourcqe

All 17 comments

@tplevko did you also edit the integration ?

@lburgazzoli thanks for the hint, it looks like after editing the integration it it works! Well, I'll just ask documentation team to place this hint also into our docs.

@lburgazzoli I'll leave this open for now, for tracking the documentation update. One question though before I let the documentation team know, the "edit" workarround is official way, how this should be done?

don't know, @gashcrumb any idea ?

I haven't the faintest idea. I can only guess that some env-specific data is getting carried across when it shouldn't be, and saving the integration after the fact updates whatever to a value specific to the current environment. So I'd say this needs more investigation :-)

@tplevko do those two instances have the same encryption key defined? You can check by examining the syndesis-server-config config map and encrypt.key property in the application.yml there.

@zregvart I checked and the encryption key is not the same

@zregvart I checked and the encryption key is not the same

I don't think we can support importing between environments with different keys then, or we have a bug in not resetting encrypted values on import. Which of those is it depends on that we agreed on implementing in the first place. I have no idea what that is.

cc @chirino @lburgazzoli

Well, the expected behaviour is that when importing an integration from a different environment, some parameters may have to be updated (like passwords) so we show a warning on connection/integration level.

Here the problem is that when you update the connections, the integration is not updated as well but keep a record of the old connection (you know, all the bits are embedded into the integration) thus you are required to edit a connection as workaround.

@lburgazzoli for now, as there is this workarround, I'll let documentation team know, so they could cover it in our docs. I think however it would be good, if this got solved in a more intuitive way in the future.

//cc @TovaCohen

@tplevko According to the comments we can lower the priority, can we?

Possibly, the current doc is fine and does not need an update. The documented procedure for importing an integration tells the user to update connections as indicated in the UI and then Edit and Save the integration. I'll paste a link to the latest user doc below. Please let me know if I need to update it and if so, exactly what the update needs to be:

https://access.qa.redhat.com/documentation/en-us/red_hat_fuse/7.1/html-single/integrating_applications_with_fuse_online/#importing-integrations

@tplevko @lburgazzoli do you think the docs cover it appropriately? In that case please close the issue.

looks ok to me, @tplevko any objection to close this issue ?

@lburgazzoli @heiko-braun the documented "solution" was and still is from my POV just a workarround for the issue, so it's not solved properly. However I think this could be closed as there are 3 almost identical issues reported: this one, https://github.com/syndesisio/syndesis/issues/2602, https://github.com/syndesisio/syndesis/issues/2603 and there is ongoing discussion & work on https://github.com/syndesisio/syndesis/issues/2602, so I'm closing this one.

@tplevko yes it is a workaround

there is a general issue about the relation of an integration and external objects such as connections that we need to discuss.

Was this page helpful?
0 / 5 - 0 ratings