Of course! I didn't mean to imply that you shouldn't secure your app, but
honestly if someone succeeds in hijacking your session, then he could
possibly do it before loading the host page, so that your GWT app will run
with the hijacked session, and the auth token in the request payload won't
Hi Thomas,
On Fri, Feb 25, 2011 at 8:49 AM, Thomas Broyer t.bro...@gmail.com wrote:
Of course! I didn't mean to imply that you shouldn't secure your app, but
honestly if someone succeeds in hijacking your session, then he could
possibly do it before loading the host page, so that your GWT app
Does this mean that auth token in the request payload is not of much use?
Also, I want to understand when i have the token set in the requestfactory
payload, how to retrieve from the payload when a service call is made by
requestfactory since i will have to validate the token for every service
On Fri, Feb 25, 2011 at 10:14 AM, veenatic praveen.bit...@gmail.com wrote:
Does this mean that auth token in the request payload is not of much use?
Also, I want to understand when i have the token set in the requestfactory
payload, how to retrieve from the payload when a service call is made
On Friday, February 25, 2011 3:21:18 PM UTC+1, Jeff wrote:
Hi Thomas,
On Fri, Feb 25, 2011 at 8:49 AM, Thomas Broyer t.br...@gmail.com wrote:
Of course! I didn't mean to imply that you shouldn't secure your app, but
honestly if someone succeeds in hijacking your session, then he could
You are talking about using request cookies so of course the scenario you
describe might be possible. Everyone knows they are vulnerable and hence
their ease of hijacking. The right way to do it is not using request cookies
at all on the server because they cannot be trusted - the auth token must
You contradict yourself (compare the HttpSession's ID with the auth token
–the HttpSession is maintained by a cookie, whose value generally is the
session's ID– vs. do not send the auth token in a cookie), but that's not
the problem.
The problem is: how are you initializing the auth token on
On Fri, Feb 25, 2011 at 12:30 PM, Thomas Broyer t.bro...@gmail.com wrote:
You contradict yourself (compare the HttpSession's ID with the auth token
–the HttpSession is maintained by a cookie, whose value generally is the
session's ID– vs. do not send the auth token in a cookie), but that's not
On Friday, February 25, 2011 6:39:40 PM UTC+1, Jeff wrote:
On Fri, Feb 25, 2011 at 12:30 PM, Thomas Broyer t.br...@gmail.com wrote:
You contradict yourself (compare the HttpSession's ID with the auth token
–the HttpSession is maintained by a cookie, whose value generally is the
I am not dismissing your scenarios outright as I never said that the method
was foolproof and I also said that only SSL will give you something close to
that.
Also lets not forget that if the user manages to be lured to an attackers
site via a link in an email for instance and then doesn't notice
I think the discussion has become very interesting and I understood a lot
about attacks and attackers but I still ponder over the question that if we
have to put the auth token on the payload of the RequestFactory, how to do
that?
And after this how to read the token from the payload to verify
With RPC I define all my RPC synchronous methods taking a string parameter
whose value will be assigned from the cooke storing the sid. On the server,
the handler will compare this string value to the value returned from the
Session.getId() method. If they aren't the same I throw a custom
btw my bad I meant to say overridden OnFailure method... sorry about that
On Fri, Feb 25, 2011 at 7:15 PM, Jeff Schwartz jefftschwa...@gmail.comwrote:
With RPC I define all my RPC synchronous methods taking a string parameter
whose value will be assigned from the cooke storing the sid. On the
Thanks Jeff,
With RPC, this way is understood. Similarily, I have some idea with
RequestFactory also like
requestFactory.serviceRequest().getAllEntities(clientSid);
and on the server side, in getAllEntities(String clientSid) i can verify the
same way you did.
But this way is forcing me to put
You could use the Command pattern as with GWT-RPC using a ValueProxy as the
command object, but I'm not sure what you'd gain by it as you'd lose all the
RF functionality related to entities. As it currently stands, you would need
to modify the RF transport protocol, perhaps with a
If you want to pass an authentication token on each request, then the
RequestTransport is the way to go on the client-side.
Have a look
http://code.google.com/p/google-web-toolkit/source/browse/tags/2.1.1/samples/expenses/src/main/java/com/google/gwt/sample/gaerequest/
which
is used
In such a scenario, you'll generally have a session maintained by the
server through a cookie, which will be enough (yes, cookies are not that
secure, but still deemed secure enough that everyone from Google to
Facebook, Twitter, Microsoft, Yahoo!, etc. use them). The RequestTransport
will
On Thu, Feb 24, 2011 at 6:19 PM, Thomas Broyer t.bro...@gmail.com wrote:
In such a scenario, you'll generally have a session maintained by the
server through a cookie, which will be enough (yes, cookies are not that
secure, but still deemed secure enough that everyone from Google to
Facebook,
On 26 January 2011 14:53, Thomas Broyer t.bro...@gmail.com wrote:
You mean how I *did* implement it? ;-)
Using the same pattern as the Expenses sample:
1. out HTML host page (the one calling the *.nocache.js) is protected
with a simple servlet FORM authentication
On 16 February 2011 12:14, Ernesto Reig erniru...@gmail.com wrote:
On 26 January 2011 14:53, Thomas Broyer t.bro...@gmail.com wrote:
You mean how I *did* implement it? ;-)
Using the same pattern as the Expenses sample:
1. out HTML host page (the one calling the *.nocache.js) is
Thank you very much for your responses Thomas and Y2i.
Maybe, this can help to other people who are (like me) changing from Tomcat
to Jetty. Refering to the web.xml and jetty-web.xml:
- I did know that jetty.home was pointing to my working directory
(C:\workspace\my_app\src\main\webapp in my
Hello again.
It seems that I get stuck in every step... The thing is that I don´t know
how to use Tomcat for the Development Mode instead of the embedded Jetty.
I´ve been reading lots and lots of docs (including
I also started from using Tomcat, but the debugging issue forced me to
switch to Jetty. It took time to learn Jetty's specifics but it was worth
it.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to
Thank you very much for your response. At the moment I´m studying jetty and
I get to a very simple question:
*¿What is or how can I know, the current Jetty version of the current GWT
version?* Now I´m using 2.1.1
This is a very simple question that I cannot understand why in the world
there´s no
Ok. Now I´m configuring the application to authenticata against the embedded
Jetty server wich comes with GWT. Please, correct me if I´m wrong:
- I have to create a jetty-web.xml in WEB-INF of my gwt application with
the following text:
Configure class=org.mortbay.jetty.webapp.WebAppContext
On Thursday, January 27, 2011 7:49:01 PM UTC+1, ernesto.reig wrote:
Ok. Now I´m configuring the application to authenticata against the
embedded Jetty server wich comes with GWT. Please, correct me if I´m wrong:
- I have to create a jetty-web.xml in WEB-INF of my gwt application with
the
Based on the below I assumed it's 6.1.23, this is what I'm using.
find . -name *jetty*
./org.eclipse.equinox.http.jetty_2.0.0.v20100503.jar
./org.mortbay.jetty.serveradaptor_1.0.4
./org.mortbay.jetty.serveradaptor_1.0.4/icons/jetty_tiny.gif
Jetty classes are packaged within gwt-dev.jar, that one comdes from
somewhere else (Eclipse WTP ?)
The version used by GWT is 6.1.1:
http://code.google.com/p/google-web-toolkit/source/browse/tags/2.1.1/dev/build.xml#62
--
You received this message because you are subscribed to the Google
Oops, sorry: 6.1.11 (but you'd have clicked the link to get the
authoritative answer, right? ;-) )
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe
thank you very much for the link. So I've been using a wrong version all
along...
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group,
Ok. If I haven´t misunderstood (reading at
http://code.google.com/appengine/docs/java/users/overview.html#Authentication_Options),
you have three options to authenticate users with App Engine:
- A Google Account
- An account from an (my) Google Apps domain.
- An OpenID identifier
BUT, if I
Following my previous post...
what I need is to provide my users with username and password, and to have
full control of the users that login in my application. I don´t want that
everybody who has a google account or an openID identifier can do login. So,
the question again:
- Is this possible
It sounds, based on the full control requirement, that you cannot deploy on
GAE.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send
Thank u for your help and comments Y2i (and the others).
To sum up, I will say that Google App Engine is a great thing to use with
your apps, but it´s designed for apps where everybody having an openID
account can log in, I mean, you cannot have your custom authentication.
- You cannot have your
I forgot to say this in my previous message:
I don´t think that including the Expenses app in the distribution of GWT is
a good idea. I ONLY SAY THIS BECAUSE OF THE AUTHENTICATION APPROACH USED. I
mean, it seems to be a custom app for a private organization/company. But as
said in my previous
Thank you Y2i. The thing is that I don´t use GAE. I´ve never used GAE
actually. But, as I said in my first comment, I want to implement the
authentication/authorization the best way (the most
recommended/professional) to do it.
If you think, from your experience, that the best way is using GAE, I
Ok. I´ve been having a look to GAE Authentication. And there are things I
don´t understand well...
If you look at this page (
http://code.google.com/p/gwt-gae-book/wiki/Authentication), which seems to
be quite reliable, it clearly says Although it's possible to develop App
Engine applications with
Sorry if I was not clear, I didn't say it's the best to use GAE, it all
depends on your requirements. GAE is a web server where you deploy your
application. If you chose to deploy on GAE then it's better to use
authentication offered by GAE.
--
You received this message because you are
Keeping on trying to fully understand GAE Authentication, with the Expenses
example approach, I find these lines of code:
UserService userService = UserServiceFactory.getUserService();
...
if (!userService.isUserLoggedIn()) {
...
}
And now I get stuck into this.
- What is that UserService?
Take a look here
http://code.google.com/appengine/docs/java/config/webxml.html#Security_and_Authentication
And then here (the first link will also point you here)
http://code.google.com/appengine/docs/java/users/
Also read the overview
Thank you very much for your responses.
So, in order to clarify things:
Is it better to use RequestFactory to talk to the server in every case? or
is it better to use GWT RPC when the user first logs in (sending the
credentials to the server and creating the session id) and RequestFactory
for
It probably does not matter, RequestFactory is just a form of RPC. You can
have 2 request factories: one for login, anther for the rest of the app.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to
It does not make sense to have 2 RequestFactory(s) in a single web app. I´d
have 2 (or more) RequestContext, and I´d get them having these methods in my
AppRequestFactory interface (one of them dealing with the user management):
ARequest aRequest();
BRequest bRequest();
The question of having
If you want to pass an authentication token on each request, then the
RequestTransport is the way to go on the client-side.
Have a look
http://code.google.com/p/google-web-toolkit/source/browse/tags/2.1.1/samples/expenses/src/main/java/com/google/gwt/sample/gaerequest/
which
is used in the
Thank you Thomas. I´ll have a look (and try to understand) the approach
you´ve recommended (used in the Expenses sample).
What a coincidende today I´ve been reading a blog
http://tbroyer.posterous.com/ Maybe you know it ;) Congratulations for your
great posts.
Thank you very much.
--
You
On Tuesday, January 18, 2011 9:05:23 AM UTC-8, ernesto.reig wrote:
It does not make sense to have 2 RequestFactory(s) in a single web app. I´d
have 2 (or more) RequestContext, and I´d get them having these methods in my
AppRequestFactory interface (one of them dealing with the user
Any comments please?
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
You need to put session code in server side
if you know the basics of session ,below code would be helpful
HttpSession session;
session= getThreadLocalRequest().getSession(*true*);
*save value in session:*
session.setAttribute(myuser, user); [ myuser-- name of the session ]
[user- any
There are many ways to implement logins, depending on the server side you
use.
If you use servlets then the servlet spec will guide you:
http://jcp.org/aboutJava/communityprocess/pr/jsr315/index.html
Look at login-config/, auth-method/, realm-name/,
security-role/, security-role/ tag
The best practice for developing GWT applications is to keep the
server-side of your code as Stateless as possible.
In the past, with traditional web frameworks, there was not much you
could do on the client,
we only had basic html forms, which we asked user for input, and most
of the processing
P.S. Forgot to mention that if you use GAE, it's better to start from this
pagehttp://code.google.com/appengine/docs/java/config/webxml.html#Security_and_Authentication
.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this
51 matches
Mail list logo
