Hi Mateusz,
me too was referrring to HTTP principles.
On the session ID (which is, at the end, a temprary access token) discussion:
these
kind of tokens are temporary, while credentials are more stable and don't
require the
processing that is associated to the valdiation of credetnials.
Yes someone can stolen your session token; but think at what happens if someone
steals a session token as compared to steal your credentials!
If I still your session token I could do something while the token is valid,
but you, for
example, are still able to login to the system. If I steal your credentials, I,
for
example, can log to the system, change the password and permanently throwt you
away from the system!
Even if you use SSL/TLS there could be risk; indeed being credentials more
stable in
time (you don't change your password every hour or day), the encrypted flow can
present some recurring patterns that help in restricting the "space" of
possible
credentials. Session tokens being temporary (especially if you take the habit
to assign
a limited time validity) add entropy to the system that avoid reducing the
possibility
for atatckers to guess tokens.
Ciao
Domenico
On 11 Mar 2014 at 2:00, Mateusz Dymczyk wrote:
I'm not talking about statelessness of HTTP but about basic REST principles.
OrientDB is trying to
expose a REST interface, which by definition is stateless. The kind of
statefulness you are talking
about also has a lot of problems (what if you have a load balancer between your
clients and
distributed DB services? you need to manage that which usually means much more
work than plain
authentication/authorization). About security you can as well say that someone
can find out your session ID the only
benefit of it is that it might sooner or later expire.
Mateusz
On Tuesday, March 11, 2014 5:32:04 PM UTC+9, Dom54 wrote:
Hi,
yes HTTP is stateless, but this doesn't mean we can't had session's concept
like
almost all web applications do.
Sending credentials with every request is a bad idea from an operational
and
security point of view.
From an operational point of view this implies that the server has to
execute the
authnetication process for each request, which implies addind overhead to
each
request has compared to simply check is a session ID exists and is still
valid.
From a security point of view resending credentials with each request
increases
the risk that the credentials are caught by others (even using TLS/SSL; see
the
patch Apple was urged to provide to fix a bug in its implementation of the
TLS/SSL stack!), unless you take specific measures to protect them (which
increase the processing overhead).
Ciao
Domenico
On 11 Mar 2014 at 1:10, Mateusz Dymczyk wrote:
REST by definition is stateless so what you are asking for isn't REST.
What's bad with sending
credentials with every request?
Mateusz
On Tuesday, March 11, 2014 4:19:26 PM UTC+9, Gaurav Dhiman wrote:
I noted that the way OrientDB authenticate user for every HTTP access is by
expecting username:password encoded in base64 for every HTTP call. Isn't
that
a bad idea.
I think, username:password should only be expected once at the time of
login
(HTTP connect call). Once connect is successful, OrientDB should return
session ID and in consecutive call to ORientDB server that session ID
should
be sent in place of username:password combination. Using sessionID OrientDB
should be able to fetch current logged-in user and and its details at
server end to
perform specific actions.
Can we achieve above in OrientDB (for HTTP REST calls) ?
Regards,
Gaurav
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB"
group.
To unsubscribe from this group and stop receiving emails from it, send an
email to
[email protected].
For more options, visit https://groups.google.com/d/optout.
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
