• May I ask if I am able to send variables that are passed to the "Command" on the localhost just like a Tasker HTTP Post action?
    It would be really great if I could send three variables and if possible up to five because this means that I can call scripts with variables that can do multiple things.
    Many thanks

  • administrators

    Good question @jgodney. For security, I chose not to allow variables passed as command-line parameters.

    I wanted to prevent a hacker who might somehow guess your password from being able to execute anything except the commands you've setup on your computers.

    For example, a bad guy could send an & or ; in the parameter field that would allow them to run any arbitrary command they wanted on your computer. Not good...

    I thought about scrubbing the parameters to remove any special characters, and only allow numbers and letters. That seems relatively safe, but then I could see people building scripts that take a parameter and execute it as a command.

    What's your opinion on this?
    Am I'm being too concerned about security at the expense of functionality?

  • Hi Russell
    You are probably aware already that you are onto something of a special thing with your Triggercmd agent, and as soon as you manage to deploy to android and iPhone I believe you are going to get allot of interest from investors because you would then have a foothold and ability across all major platforms.

    Just by installing an accessible agent on a device wipes out the most robust form of security, which is inaccessibility. Then opening channels\triggers over the agent diminishes the security further.
    I believe security needs to come at the point of accessing the exposed webhook\agent on the device and not in limiting the functionality. By allowing variables you are enhancing your potential market place to automation specialists. The ability to only initiate a static predefined trigger is very restrictive.

    Your concern is warranted, as there is a posibility of a breach in security especially because a simple key does not offer much of a security blanket. Maybe offer a warning that if the end user "enables" variables on a trigger he is increasing his risk. Maybe upgrade accessibility security to certificates as used by virtual private networks. Maybe limit the originating request to zapier and other trusted services.

    If you gave me the option in my use case I would enable variables.
    Thanks for considering it.

  • administrators

    @jgodney, thank you for this feedback and for thinking about this with me. I agree it would open up a lot of capabilities if you could pass a parameters field, so I should figure out a way to do it securely. If you enable that feature on the agent itself rather than in the cloud, it would be secure by default. I'm thinking it should be a boolean flag on each command which would default to false, and like you said, the GUI should warn the user about turning it on.

    The idea of limiting the API client to Zapier, and maybe IFTTT is interesting, but probably too limiting again.

    I'm also interested in your ideas for the Android and iOS apps - do you mean a client app or an agent? The Android app I published so far is just a wrapper for the web interface, but I'd like to improve it at some point.

  • has a good idea with their agent\app on the and even better on the Android but with the flexibility of your solution and your automation focus, you would be a much more attractive all round management platform.

    @Russ said in HTTP POST:
    If you enable that feature on the agent itself rather than in the cloud, it would be secure by default. I'm thinking it should be a boolean flag on each command which would default to false, and like you said, the GUI should warn the user about turning it on.

    Yes this arguments functionality could work well at the time of agent deployment and it does sure up the security with the functionality being disabled by default and only enabled on a task by task basis on the agent. Maybe the warning should also point the user to an article online that helps them to understand the vulnerability they would be opening up. A boolean flag sounds good and simple.
    This would be a good strategery while access to agents via the cloud is still controlled by a key string.
    I would, however, suggest that all task initiation channels are checked and enabled and documented for arguments to be passed to each task so that the Task and local Command can use it. E.g. POST commands and Zapier... (after thought: that probably did not need to be said)
    This arguments functionality would revolutionise your solution with developers and automation specialists integrating your solution. I am one who would be using it in a production implementation right away.

  • administrators

    @jgodney, yea I'm convinced - TRIGGERcmd should support an optional parameters text field for each command. I'll work on it.

    I'd never heard of Integromat. Now I want to setup an integration for that too.

  • administrators

    Check this out.

    I opened my commands.json file in Notepad via the API using Postman. I'll publish a new agent version that will support parameters soon.


  • administrators

    It's ready. Please give it a try. I put some details in this accouncement and this IFTTT article. More to come - like passing parameters from Zapier.

    Thanks for this suggestion - this is really cool. I just setup an IFTTT trigger to display any pictures I add to a Google Photos album.

Log in to reply

Looks like your connection to TRIGGERcmd Forum was lost, please wait while we try to reconnect.