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/
