Hi! My only pending question is the best way to send a message from PHP to APE (the other way around I have MySQL as bridge which is fine). I see in your example you use html include (we could use curl), but the thing is: how would you prevent a "bad" user to spam another user (for example) by using the exact same URL you did in PHP?
I was thinking to test the referer in APE (if possible) to check the IP used is localhost, but it does not seem very nice to me, if it works. I was wondering about a commandline tool for APE, but did not receive any update on this. Do you have a better idea on how to do that? Like Nouk said, using a Socket connection would be a way, how to do this,but it comes with a bit more complexity. On the other Hand, in my (simple) example there are also some things whichwould prevent a user from sending on the push-channel.First of all there is a password (like in the Controller demo), which has to be known.Second, there is the command and the parameters which must be known.But most important, the secret key must be known to the bad user, otherwisehe´d just send messages "in the wild". While agree, that using a connection from PHP to APE, which can be onlyestablished locally, would be the best (most secure) solution, it is not reallyeasy to exploit the "normal" way, for there a lot of things which had to be known to a "bad user" and you can put in even more. Timo --- Cadrach <[email protected]> schrieb am Do, 18.3.2010: Von: Cadrach <[email protected]> Betreff: [APE Project] Re: secure inlinepush - blogpost An: "APE Project" <[email protected]> Datum: Donnerstag, 18. März, 2010 00:20 Uhr Hi, I have implemented something a bit similar in my own project, what I do is the following: I have a PHP/MySQL app, with session handling through MySQL (check http://php.net/manual/en/function.session-set-save-handler.php for an example, or better, work with ZendFramework). This means that all my PHP session data is in MySQL, so when a user connects to my PHP app, he gets a row in the session table with his session id. This is matched directly with the userId my project is using. Now on the client side, when the user connects to APE, I send the PHP session id that you can get from the session cookie on any page of your site, and sends this much like you do your secretKey. On APE server side, I receive the phpSessionId and use it to find the user line in MySQL. If I do, I update a field called apeSessionId in my session table with the APE-generated userId. This is where I stand now, meaning I could use the apeSessionId to update a user through PHP very clearly, or modify a user info through an APE event. My only pending question is the best way to send a message from PHP to APE (the other way around I have MySQL as bridge which is fine). I see in your example you use html include (we could use curl), but the thing is: how would you prevent a "bad" user to spam another user (for example) by using the exact same URL you did in PHP? I was thinking to test the referer in APE (if possible) to check the IP used is localhost, but it does not seem very nice to me, if it works. I was wondering about a commandline tool for APE, but did not receive any update on this. Do you have a better idea on how to do that? And thanks for the nice read on your blog, Cadrach On Mar 17, 4:02 pm, Timo Michna <[email protected]> wrote: > Hi! > First the pubid must be known to the script/application doing the inline > push.So there must be some kind of publishing the pubid in a connect > hook. That´s a minor problem but comes with some complexity. > True, but wouldn't the push app need to know the hidden key also? > Well, yes, at least the push app must be aware of the user anyhow, or > sendinga private message would make no sense.In case of a webapplication > there is in most cases a session-id available.The drawback of using the > session-id is that it might differs when you are loggedin with different > browsers (I do this sometimes for I use different browsers fordifferent > purposes).However if the webapp is the same as the push app the secret key > must onlybe stored/cached somewhere and can be referenced later.In my case > I´ll use a implementation of eai-patterns in PHP I am working on(similar to > spring integration), in which one could completely decouple theknowledge of > the secret-key from the push app. In that case it is only sendinga message on > a special channel (not APE channel), where a resolver and service activator > will take care of sending the message to an APE client (or somewhere else). > Depending on configuration it could look like > this:[...]$context->getGateway('ape_secure_gateway')->sendAndReceive($user, > "private message");(some kind of publish-subscribe-channel with a gateway for > decoupling) That´s indeed a very special case, only to illustrate where I > want to use this scenario. > The second one is, that the solution is meant to be used with allready > existingUser accounts. So there must be a way of preventing a "bad user" to > connectto a channel with someothers username/nick or otherwise preventing us > fromsending him private messages. So how can we make absolutely sure, that we > broadcast to the right user? As far as I can think, only by using some kind > of secret/session key.Are you talking about both sending a private message > and authentication? > I meant that this scenario only makes real sense when you have some kind > ofauthenticated user in the first place, to whom you want to send messages > orcommands for the client later. Let´s say you have some kind of > social-network application (aka "User-Profile wrapped with something else") > where Users can send private messages to each other.In that case you could > inform a User, when he has got a new PM via APE (in eipyou could use a > wire-tap for this). But since the authentication process is unlikely done > through APE but through thewebapp, you must be sure that the User with > Nickname "Foo" in APE is the same as the User who`s Username is "Foo" in the > webapp. You could indeed send those messages only to logged in users in the > webappand make sure they connect with the right username/nickname to APE, but > thereis still a latency between authentication (logging in) and establishing > the connectionwith APE which can be some seconds. For example: If > I´d sit next to you and see you logging in, I could make a connection to APE > with your Username (when I now it) and receive all your PMs and you couldnot > even connect.While this is a special scenario, there are people who a very > creative in findingsecurity holes and using exploits. You could even use the > other way around and send spam messages. While absolute security is an > illusion, you just don´t have to make it so easyfor potential attackers.So my > solution is just a way of giving a authenticated user some kind of tokenwith > which he can connect to APE and say "I want to receive messages for theuser > with that token". So actually a way of preventing a double > authentication process - one in the webapp and another in APE (which would be > even safer but not very user friendly). Timo > > --- Perrin Perrin <[email protected]> schrieb am Mi, 17.3.2010: > > Von: Perrin Perrin <[email protected]> > Betreff: Re: [APE Project] secure inlinepush - blogpost > An: [email protected] > Datum: Mittwoch, 17. März, 2010 02:21 Uhr > > First the pubid must be known to the script/application doing the inline > push.So there must be > some kind of publishing the pubid in a connect hook. That´s a minor problem > but comes with some complexity. > > True, but wouldn't the push app need to know the hidden key also? > > > The second one is, that the solution is meant to be used with allready > existingUser accounts. So there must be a way of preventing a "bad user" to > connect > to a channel with someothers username/nick or otherwise preventing us > fromsending him private messages. > So how can we make absolutely sure, that we broadcast to the right user? As > far as I can think, only by using some kind of secret/session key. > Are you talking about both sending a private message and authentication? > > There already is a sessionid which the user sends to ape to retrieve there > own message. As far as I know the sessionid isn't broadcast to other users, > but the pubid is. > > -- > > You received this message because you are subscribed to the Google > > Groups "APE Project" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > > http://groups.google.com/group/ape-project?hl=en > > --- > > APE Project (Ajax Push Engine) > > Official website :http://www.ape-project.org/ > > Git Hub :http://github.com/APE-Project/ > > __________________________________________________ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz > gegen Massenmails.http://mail.yahoo.com -- You received this message because you are subscribed to the Google Groups "APE Project" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/ape-project?hl=en --- APE Project (Ajax Push Engine) Official website : http://www.ape-project.org/ Git Hub : http://github.com/APE-Project/ __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- You received this message because you are subscribed to the Google Groups "APE Project" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/ape-project?hl=en --- APE Project (Ajax Push Engine) Official website : http://www.ape-project.org/ Git Hub : http://github.com/APE-Project/ To unsubscribe from this group, send email to ape-project+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
