Hi Guys,
I have an application which is build by using GWT. I want to implement some
user authorization mechanism for it. Basically i want to restrict some of
the functions for specific user groups in client side . What will be the
best approach for this ? How do we restrict certain feature from
You could load your user credentials on app start and then set UI controls
visible/invisible based on the users credentials. But that only makes the
UI nice for the user. You still have to check for the same credentials on
your server so that your server disallows any server actions that the
Hi Jens,
Thanks a lot for your quick reply. Actually my application has lot of Ui
classes (More than thousand)and various types of user groups. If i have to
check user permission manually and add if-else for each and every component
that will be a huge amount of work.I'm just wondering weather
Well actually you have to call setVisible/setEnabled a thousand times if
you have thousand widgets to configure.
You can either do it explicitly by if/else for each widget all across your
code base or you search (maybe DOM based)/register the relevant widgets.
But that still means you have to
On 06/03/2013 12:58, dilantha silva wrote:
Thanks a lot for your quick reply. Actually my application has lot of Ui
classes (More
than thousand)and various types of user groups. If i have to check user
permission
manually and add if-else for each and every component that will be a huge
Hi Guys,
Thanks for your replies. I came across this framework called Acris. Which
seems to have the features that i was looking for. But it is bundled with
maven . Since im not familiar with maven and my project is not build using
maven im not sure how am i going to use acris [?].
After reading a lot about this topic, I have the following questiong.
My scenario is a login page (user/psw) and then depending on the user
role, he can navigate/view some panels or others.
Is this log-in flux correct?:
1-Client sends usr/psw
2-Server verifies it an if it is correct, load the
Hi Juan,
Your login flow is correct.
The discussion about sending a session ID in the payload (vs. just a cookie,
which the browser sends automatically in HTTP headers) is to prevent XSRF
attacks. You can find more info here:
http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
Luis, the way you see it is completelly wrong. If you are looking only
for a way to encrypt data sent to the server, stop wasting time
researching 3rd party libraries, instead visit www.verisign.com, buy a
certificate and use SSL! There just is NO OTHER WAY to provide better
encryption for the
why is more acceptable for you, that user will see whole application
(also the screen which is not allowed to use) rather than ONLY screens
that he is able to use.
Simple:
1: User documentation on how to use the program is consistent.
Everyone sees the same menus, screens, screen layout, etc.
2:
Greg, do you realize, that there are administration possibilities/
functionalities/menu items here on google groups too ? No ? It is
because you CAN'T SEE THEM, because you ARE NOT THE ADMIN. I don't
know, what kinds of applications you use, but I just can't possibly
imagine a bank application,
Hi Greg,
why is more acceptable for you, that user will see whole application
(also the screen which is not allowed to use) rather than ONLY screens
that he is able to use.
Your argument becomes to me little bit funny: tech support and UI
nightmare. If you have correctly setup user permissions,
its a way it works, like Greg said - a dumb client should not worry,
or better said not be too serious about security, everything what
happens on the client is INSECURE, so the only security concern it
should think about is to make the security look good to its user.
the real security should
I'm not talking about the data. Secured data, that user is not allowed
to minupulate with, are not sent to client! This logic is done on the
server side security implementation.
I'm talking about displaying the screens and securing the components:
- like if the user is not able to maintain users,
oh yeah, totally right , this what I mean by make security look good
to the user ;)
On 12 Aug., 09:42, Peter Simun si...@seges.sk wrote:
I'm not talking about the data. Secured data, that user is not allowed
to minupulate with, are not sent to client! This logic is done on the
server side
Personally I would like to know proper name for it
I'd go for Consistent UI design. Which, I admit, doesn't sound
nearly as sexy as improved security. BUt that is what you're doing:
you're keeping the UI consistent with what the user is allowed to do.
Another way to put it is don't tease the
I'm talking about displaying the screens and securing the
components.
The problem is that that is a meaningless statement, and to the extent
that it's not meaningless, it's pointless.
I suppose you could set up your code so that the JS to display a
screen isn't downloaded unless the user will be
I don't see anything about the encryption used in the RPC call to the
userservice... so it's just a fancy 3rd party RPC call, no security
there...
On Aug 10, 3:20 am, Peter Simun si...@seges.sk wrote:
Hi all,
I just wanted to share with you the article about security in GWT
there is no reason to secure it, since decryption logic would be in
javascript - thus public accessible, so better to use https ;)
On 11 Aug., 14:04, Luis Daniel Mesa Velasquez
luisdanielm...@gmail.com wrote:
I don't see anything about the encryption used in the RPC call to the
userservice...
I don't think that security is just about encrypting RPC calls. And as
cokol said if encrypted RPC stream is the only concern it should go
through HTTPs. The purpose of acris-security is to integrate server
side security with GWT client, propagating authentication and
authorization things (like
Luis, why do you think that there is no security there?
Please, read the article again and carefully, or go on the wiki pages:
http://code.google.com/p/acris/wiki/Security
Peter
On 11. Aug, 14:04 h., Luis Daniel Mesa Velasquez
luisdanielm...@gmail.com wrote:
I don't see anything about the
Hi Peter,
I had just a glance at acris.
Acris is talking about a client side part.
No mechanism which depends on client side code could be secure!
So I would suspect acris to be a misconsception.
At the moment I do not spend time to exactly find out what is wrong
with acris.
Stefan Bachert
Hi Stefan,
of course, client side code could never be secured! AcrIS security
fully depends also on securing the RPC services (on the server side,
client side security is an complementary security - some kind of nice
to have security)
The goal is: if the user does not have rights to see some
This seems to me just a flame about what the word 'security' exactly
is :) acris-security is about bridging client and server, using
server's authentication and authorization methods to add another layer
for potencial attacker to skip (for common users what is not visible
or editable is also not
Hi Peter.
Not to be rude, but who cares?
Who cares if the user can see a screen that says Client Data, when
the user can't actually download any of that client data?
IOW, what's the point? If your sever is properly secured, then users
who aren't allowed to see the client data won't be sent it,
Hi Greg,
thanks for the answer. Who casers? Users cares!
Let's imagine that you will modify all the data you are able to
modify (as an user of the application) and the the server will
response you, that you are not allowed to modify them! Are you
satisfied with that solution? Is that a common
Personally I would like to know proper name for it, if you would be so
kind and give us some proposals we will consider it as your
contribution to the process of making acris-(currently named)-security
better :) We initially thought that 'security' also covers
transferring server-side security
Hi all,
I just wanted to share with you the article about security in GWT
application.
http://java.dzone.com/articles/securing-gwt-client-acris
Serious security implementation is something that was missing almost
to each GWT developer. I saw many topics here in the forum about the
security, so
Hello,
Is it possible to have differente security-constraint for different
web application areas.
For example, if I have different user-groups how can I manage access
control.
I'd like to block users without sufficient credentials to view secret
web areas.
I've just set up a login form and an
Hi;
I am developing a GWT application which I try to make more secure with
database based authentication. I read a lot of articles but I am still
not so sure about which practice is better for me. I don't know much
about spring and I never used it. But I read in the articles Spring
Security is
30 matches
Mail list logo
