but RPC & REST is not possible. ???

i forget the ?

On Jul 7, 3:19 pm, ytrewqsm <[email protected]> wrote:
> Thx ... but RPC & REST is not possible.
>
> I prefer using RPC as well.
>
> On Jul 7, 2:50 pm, "brett.wooldridge" <[email protected]>
> wrote:
>
>
>
> > GWT can support REST easily.
>
> > See:
>
> >http://code.google.com/webtoolkit/doc/1.6/DevGuideServerCommunication...
>
> > The section on Making HTTP Request should help.  Personally, I opt for
> > standard GWT RPC, but I'm a spoiled Java coder.
>
> > -Brett
>
> > On Jul 7, 5:18 pm, ytrewqsm <[email protected]> wrote:
>
> > > Thx a lot...i got a lot of information...i try now to process all of
> > > it.
> > > Still after first reading ,REST like application is based on url's and
> > > stuff
> > > How can that be applied to a GWT app which is based on RPC.
> > > This is like a one page application....so ?
>
> > > On 7 Iul, 05:00, "Dean S. Jones" <[email protected]> wrote:
>
> > > > Yes, I work in banking, so I tend to see the world through "paranoid
> > > > color glasses", my above replies really only scratch the surface of
> > > > required precaution, but you get the idea. For most people, "state in
> > > > the client" + cookies or RPC tokens will do. Also, the GWT compiler/
> > > > optimizer/minimizer makes it damn hard to even have a chance of
> > > > understanding the generated JS, let alone hack it.
>
> > > > That said, if your site is public facing, you should take some
> > > > reasonable measures to protect it.
>
> > > > On Jul 6, 9:26 pm, "brett.wooldridge" <[email protected]>
> > > > wrote:
>
> > > > > Nice.  And as noted by Dean, this is a financial/banking application.
> > > > > You have to go the extra mile and then some in that case.  That said,
> > > > > most of the "rest of us" (including the likes of gmail, ebay,
> > > > > facebook) aren't overly concerned with user's messing with their
> > > > > cookies.
>
> > > > > -Brett
>
> > > > > On Jul 7, 8:36 am, "Dean S. Jones" <[email protected]> wrote:
>
> > > > > > My recent experience was to not trust the client AT ALL. If you send
> > > > > > any info to the client ( Cookie, or a token to be sent back on RPC 
> > > > > > ),
> > > > > > someone with
> > > > > > knowledge enough could use a JS debugger and modify the memory
> > > > > > containing the token, and your busted.
>
> > > > > > Personally, I use multiple methods. Everything is over https, the
> > > > > > cookies are marked secure. The cookie is reset each request with a
> > > > > > value from initial sign in, plus a "next sequence number" that is...
> > > > > > non linear, and SHA-1 encoded. The SHA'd cookie value, a "state
> > > > > > token***" + IP address of the last request are recorded in "shared
> > > > > > memory" in the cluster(Terracotta) for the session ID. If the next
> > > > > > request does not match, or the source IP does not match, we refuse 
> > > > > > the
> > > > > > RPC, kill the session, and redirect them back to sign in. ( We don't
> > > > > > worry about the various cases when a source IP can change ( this is
> > > > > > banking software ), because the clients ID is associated with a
> > > > > > whitelist IP range for the clients registered 
> > > > > > sites/proxies/gateways),
> > > > > > each RPC IP then is also checked against the client whitelist. The
> > > > > > "state token***" is sort of a FSM key - for any given action/screen,
> > > > > > the "possible next request" is a known subset of all operations in 
> > > > > > the
> > > > > > system. The request must be in that set - or a "navigation" to 
> > > > > > another
> > > > > > higher level in the theoretical FSM. i.e. if you last request was
> > > > > > "fetch portfolio instruments", the next can only be portfolio
> > > > > > operations, or nav "higher", not an arbitrary "change user settings"
> > > > > > RPC, etc.- Ascundeţi textul citat -
>
> > > > - Afişare text în citat -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" 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/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to