having pidgin run commands from the im windows?
anksingla at gmail.com
Sun Dec 2 14:58:14 EST 2007
It seems like that should be easily plugin-able currently. The hardest
part, I think, would be the UI to collect a) what to trigger on, b)
who to trigger for, and c) actions to perform per trigger. If you
develop this for yourself, you could hard-code that with #defines or
Disclaimer: This is not me volunteering to do it. Just saying it looks
doable and it shouldn't be all too involved.
On Dec 2, 2007 2:52 PM, Mike Jones <eternalorb at gmail.com> wrote:
> Ankit Singla wrote:
> > EternalOrb at gmail.com wrote:
> >> """""* Conor Fitzsimons had this to say on [01 Dec 2007, 23:36:37
> >> -0500]:
> >> It sounds like you want to use the command API in purple. Look at the
> >> uses of purple_cmd_register in pidgin source.
> >> We can probably have a 'Command API How-To'. John? :D
> >> Sadrul
> >> """""
> >> as a branch from the above, would it be possible to modify the above
> >> suggestion to include not only commands that effect pidgin that the
> >> local user enters (see examples above),
> >> but to grab command text, which i would assume needs a specific
> >> formatting, that could run commands on a local machine via input from
> >> a remote user?
> >> as an example: my roommate and myself constantly torrent, but many
> >> times the other is not in the apartment, and has his door locked.
> >> well, if our torrents are leaching bandwidth to the point that
> >> webbrowsing is pointless, it would be a nice thing to simply be able
> >> to send the other an IM
> >> (both of us use pidgin) saying something to the tune of "-/- close
> >> torrent program", and on our local machines, we could have pidgin
> >> configured that when it received that message, it would follow a
> >> specific set of user defined instructions, namely, close the torrent
> >> program.
> > Hm...if I understand you correctly, you want a way for another user to
> > run commands on your computer. Correct me if I'm wrong, but isn't that
> > a huge security risk? I'm sure it's possible to implement. It would
> > require parsing every incoming message and if one comes in starting
> > with a certain string then run whatever follows as a command. It just
> > seems like a bad idea.
> >> i must admit, i am not all that familiar with operating systems as of
> >> now, i dont begin coursework on them for another term, and i havnt
> >> had time to keep up with all the changes that all of the pidgin
> >> developers have made. so i believe that my question may be completely
> >> out of place seeing as
> >> other programs can accomplish the same result. but i do intend to
> >> take a look at the command API, now that youve suggested it. cant
> >> blame a guy for asking though, right?
> >> Cheers-
> >> -Mike J.
> >> _______________________________________________
> >> Devel mailing list
> >> Devel at pidgin.im
> >> http://pidgin.im/cgi-bin/mailman/listinfo/devel
> it is a huge security risk if done incorrectly. with my specific
> example, it would possibly be a modification of the buddy-pounce
> feature. where only my roommates account was given that ability, and it
> would only work if he matches exactly the input that the pounce
> specified. in the example, if my roommate, and only my roommate were to
> send "-/- close torrent program", than pidgin would execute a set of
> steps that i programed into the pounce. if my roommate were to send
> anything else, it would essentially be considered nothing but text. and
> if anyone else were to send that, it also would be considered nothing
> but plain text.
> the parsing itself isnt that significant of an issue, a FSM could easily
> be used to see if, say, the first three characters matched exactly to
> the "command" string. if that check failed than pidgin does nothing.
> there are previous examples of how that could be done. for the
> battle.net server run by blizzard for their multi player games, users
> typically used "bots" which scanned every message in the chat to see if
> it was a command to it, and if it was it executed that command. some
> bots were capable of modifying files on the host's computer, and that
> was generally considered a mute security risk, as there was a very
> specific access list generated by the host of the bot and denied to
> access to all others until specific permission was given.
> so, the overhead of this would only be parsing if the incoming message
> was the command trigger, and only if the person sending the message was
> given that option. until the command trigger is issued, than only that
> message needs to be worries about, and operation can return to normal.
> for the general IM user, this feature probably wouldnt even be noticed.
> but there are cases, as my example above even, where some more advanced
> users would find it nice.
More information about the Devel