It sure would be nice to have a default implementation as part of the
GWT, baked in if you will. Maybe just include a module, a extra jar or
two, etc... and write a little code or a few lines of configuration
and have a login page (you specify a html/jsp/etc... or you build
dynamically with GWT) which calls your specified code with the login
page values. If someone needs to use a different implementation or
not use it they simply do not include it.
This built in Authentication/Authorization covers the rpc calls errors
when a session times out, login page, remember me, etc.... All the
things people expect a web application to support. Security is
fundamental to Web Applications and should not be so painful to
implement when using a Web Application framework.
Consider cross-posting this in the GAE forum.
Security can only be provided by the server. So it depends on which
server you use. If you use a JavaEE server, you can use JAAS (I don't
find it very hard to configure). If you use PHP, you use whatever is
cool in PHP. GWT is mainly a client side framework (with GWTRPC as a
possible bridge to a Java server).
Yes, you're right, the GWT documentation (or some blog somewhere)
could provide an example how to set things up for different scenarios
(note that there _is_ documentation on this for AppEngine in the GWT
tutorial! And it involves only a few steps.)
Just my opinion, but maybe this is because I wouldn't want to hide
security anyway.
Chris
On Mar 5, 11:17 am, Chris Lercher <cl_for_mail...@gmx.net> wrote:
> I personally wouldn't expect an authentication/authorization component
> from a client side framework. Especially, because the login/logout
> often happens outside the context of the GWT app.
Often is not always. The GWT app needs to know about login/logout
though.
> Security can only be provided by the server.
Not sure i fully understand what you are getting at here. Yes, your
data is coming from the server, just as all data from a web
application which does anything. The client still needs to know
various things about who is logged in and what they can see.
>
> Yes, you're right, the GWT documentation (or some blog somewhere)
> could provide an example how to set things up for different scenarios
> (note that there _is_ documentation on this for AppEngine in the GWT
> tutorial! And it involves only a few steps.)
GWT does not have to be used as part of the AppEngine.
From my perspective, security bridges both the client and the server.
Right now it is very painful to implement and feel good that you
covered all the basis. IMO, the whole point of a Web Application
Framework is to simplify development. Authentication/Authorization is
currently a pain in the ass to deal with and I do not see why it needs
to be.
Application implementation features are so sufficiently disparate that
they discourage specific toolkit implementations.
Of course it should, because it would be inconvenient for the user, if
the client presented links etc which will eventually fail, because the
server denies to send or store the necessary data. But what the client
does is strictly not about security - no part of a web app's security
may depend on this. Client side code is arbitrarily modifiable by the
user. The client part is just about the UI logic you derive from the
user's roles, or from data that is associated with the user. It
doesn't authenticate, and it doesn't authorize. Under no circumstance,
the server sends or accepts data that isn't accessible by the user.
And your UI logic is something that completely depends on your app.
> > Yes, you're right, the GWT documentation (or some blog somewhere)
> > could provide an example how to set things up for different scenarios
> > (note that there _is_ documentation on this for AppEngine in the GWT
> > tutorial! And it involves only a few steps.)
>
> GWT does not have to be used as part of the AppEngine.
Exactly - but this is the server component provided by Google. For
servers from other vendors, use their security mechanism, or any good
server side framework.
> For servers from other vendors, use their security mechanism, or any good
> server side framework.
Which is what i am asking for...GWT should include an Authentication/
Authorization framework, as security is needed by most all web
applications. Authentication/Authorization is currently treated as an
afterthought rather than being baked into the framework, and it is
painful to do "right".
So how does one implement Authentication/Authorization? Roll your
own? what about things like Spring Security? No one should use that?
Database access is also something that is used by almost every web
application. You can use JDBC, Hibernate, JPA, JDO, whatever you want.
The basic question is: What's the advantage of it being a part of GWT?
Would it be sufficient to you if the GWT team suggested the "best"
framework to use?
I don't remember your earlier posts. You might have mentioned that
you've reviewed the "best practices" recommendations at the Google
Groups home page. If you haven't, I'd start there.
> what about things like Spring Security? No one should use that?
I'm guessing that a search of the list archives will uncover some useful
advice.
There is far too much hand waving and "the rest is left as an exercise
for the reader" going on with GWT and authN/authZ. We need concrete
examples and code.
On Mar 5, 9:21 am, Marley <nathaniel.au...@gmail.com> wrote: