No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Logon/Logout/Security and SmartGWT

    I'm having a lot of trouble getting my head around security in SmartGWT. It seems there is nowhere (or at least I can't find anywhere) that explains how to implement a logon/logout setup in SmartGWT. I've scoured the forums and looked at all the links and just about everything I've found either references SmartClient, SpringSecurity, or similar. The few links I've found that don't use extra libraries glibly say you can use the standard J2EE security mechanisms - but that doesn't make sense to me. The standard J2EE form-based security relies on having multiple web pages - but SmartGWT doesn't use multiple web pages - just one.

    Is there anywhere that I can find a detailed description of how to implement logon/logout/security for a web app using SmartGWT alone?

    I'm seaching exactly for such kind of how-to.

    I view in this forum at hread called how to relogin.

    I'm not that an expert with smartGWT / GWT (C++ / old java ;-) VB and matlab programmer) but i like the polyvalence of GWT.

    Am I missing something ? It is supposed to be clear?

    I,ve found also an encapsulator for spring security

    but it needs gwt-gs can we make work with smartgwt ?

    I know that some may awnser buy things A$$$ with things B$$$ but i don't want overkill security feature, only a basic one...

    Some have other tutorials how to's in mind ?



      Yes, I've seen that thread, too ( But in several places it references SmartClient (which we don't have) and it also needs SpringSecurity (which we don't want unless it's absolutely necessary).

      What I want is something that will tell me what is necessary (not optional, but absolutely necessary) in terms of add-ons, and how to get security working with SmartGWT (the LGPL version) withOUT optional extras.

      Surely somebody somewhere must have done this?


        Guys, your problem is not SmartGWT, it's lack of basic familiarity with web application security. Read a few tutorials on that topic. SmartGWT is no different, it's just servlets.



          You're right.

          I think i'm not that familiar with "implements" philosophy and the web.xml conf and other conf. I've found a tuto on basic security with session ID and GWT.

          I'm keeping reading on that.

          Well' if any reader here have a well made tutorial or something useful, could be great.

          I'll keep posting the thing i'll found.



            "The standard J2EE form-based security relies on having multiple web pages - but SmartGWT doesn't use multiple web pages - just one."

            Look here:


              Originally posted by s.simon
              "The standard J2EE form-based security relies on having multiple web pages - but SmartGWT doesn't use multiple web pages - just one."

              Look here:
              I'm aware there are frameworks for multi-page GWT (and SmartGWT) implementations - but they are frameworks to handle that exceptional case. As Isomorphic himself says in another thread, "'Going to another page' in SmartGWT just means hiding some components and showing others."


                Originally posted by Isomorphic
                Guys, your problem is not SmartGWT, it's lack of basic familiarity with web application security. Read a few tutorials on that topic. SmartGWT is no different, it's just servlets.
                With all due respect, that's not the case. I'm familiar with basic web form-based application security - but that relies on several things that seem to not be applicable to SmartGWT, such as individual (and different) error pages, logon pages, etc. As you say in another thread, "'Going to another page' in SmartGWT just means hiding some components and showing others.", yet standard web form-based security relies on having a number of different pages to which the application is directed at various times. Central to the entire concept is that various pages are protected and require login - but in SmartGWT (as you say) there aren't pages - just one page. I've no doubt there are ways to do it - but it's simply not true to say that we can use the standard J2EE security mechanisms (without substantial rework).

                I really don't understand this. There are any number of tutorials and examples of how to implement standard web form-based application security with J2EE. There's even some on how to implement it with GWT. So why isn't there a single one on how to implement such a crucial function in SmartGWT?
                Last edited by Budfudder; 29 Jun 2010, 21:06.


                  All of these approaches apply to SmartGWT as well.

                  You can implement, for example, simple realm-based security with Tomcat, using a plain HTML login form not written in GWT / SmartGWT, and simply redirect to the SmartGWT application after login. The SmartGWT application is just something at a URL, so it can be protected like any other resource.

                  You can also simply take a GWT login tutorial that involves a plain GWT (non-SmartGWT) login form and use that. Again, just redirect to the main application after login.


                    Can you please explain how we will handle the session timeout scenario.

                    For example:- There is a search text box and a ListGrid used to display the search result. The expected behavior is when the session is timeout and user try to search something, he should be redirected to login page. Since the search is a AJAX call using datasource, even if we know on server that session have expired and try to redirect it to login page,it doesn't work and we get only one server error popup on the client site.

                    NOTE : No reply means you also don't know how to handle this situation.


                      No, no reply in this case would mean you've asked a question covered prominently in documentation, specifically, the QuickStart Guide's Relogin section.

                      If you want to direct questions to Isomorphic and expect a response, buy support.


                        Exactly thats what you want, people to buy your support. Intentionally you have not given all the information properly, once the user buy the licence now he is in your trap, he don't have any other option than buying your support.

                        Good job....


                          Please ignore the noise..

                          Since this discussion the Declarative Security feature was introduced, and there are examples on the public wiki ( of how to set this up with various authentication systems (Tomcat Realms, JBoss LDAP, Spring Security), including Relogin setup.

                          Again there's nothing special that needs to be done to set up authentication for SmartGWT other than optional Relogin handling. But these samples which demonstrate Declarative Security (not just simple authentication but role-based authorization) happen to include sample authentication setups for the various systems shown.


                            Hi everyone,

                            I was looking for the same information as you. Please see and check if it suits your needs. I'll do the same now.

                            Best regards,

                            PS: @Isomorphic: Thank you for the wonderful framework and the possibility to test it. I really love it so far, even though I can't develop as much as I want. It would be almost impossible to do stuff SmartGWT offers out of the box on my own or even with another framework.


                              SmartGWT Form based login/re-login with Oracle and Tomcat: It works!

                              Hi all,

                              I tried to integrate the example into my Testapp and it works.

                              My Setup: SmartGWT current evaluation, Tomcat 7.0.23, Oracle 11 XE, Eclipse Juno + google Eclipse plugin for 4.2.

                              Here is how it's done:
                              1) In order to use the login/relogin dev and prod environments should be the same. This means in my case Tomcat also as dev, instead of Jetty. Debugging on Tomcat is dead-easy, just debug as "Web Application (running on external server)", enter your Tomcat info and disable the Embedded Server in the Eclipse Debug configuration.

                              2) In order to debug, the application has to be already deployed in Tomcat. So just build+deploy it from time to time.
                              Here is some caveat to watch out for (see: The debug-mode only uses the src/ part of your app, not the rest, including the ds.xml files. So you have to keep them updated on your own. This is done via deploying or for the lightweight ds.xml changes with an ant task:

                              	<target name="copyDSFiles" description="copy DS files and other non-src stuff to Tomcat">
                              		<echo>Cleaning Tomcat DS directory</echo>
                              		<delete dir="C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\myapp\ds" failonerror="false" />
                              		<echo>Copying new files</echo>
                              		<copy todir="C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\myapp\ds">
                              			<fileset dir="war/ds" includes="**" />
                              3) The j_security_check setup is 1:1 as in the SmartGWT wiki. Attention: Do not move the login.html etc. to another path, leave them as siblings of the main html in "war".
                              4) For Oracle instead of mySQL use this in your main Tomcat server.xml:
                              			<Realm className="org.apache.catalina.realm.LockOutRealm">
                              				<!-- This Realm uses the UserDatabase configured in the global JNDI resources under the key "UserDatabase". Any edits 
                              					that are performed against this UserDatabase are immediately available for use by the Realm. -->
                              				<!-- <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase" /> -->
                              				<Realm className="org.apache.catalina.realm.JDBCRealm" driverName="oracle.jdbc.OracleDriver" connectionURL="jdbc:oracle:thin:@localhost:1521:XE"
                              					connectionName="myschemaname" connectionPassword="mypass" userTable="T_LOGIN" userNameCol="LOGINNAME"
                              					userCredCol="HASHCOLUMN" userRoleTable="V_LOGIN_ROLE" roleNameCol="ROLENAME" digest="SHA" />
                              Also copy ojdbc14.jar to Tomcat 7.0\lib.
                              The standard UserDatabaseRealm used for the manager-servlet does return some element, the ServletLogin class from the example can't use (invalid cast exception in "GenericPrincipal genericPrincipal = (GenericPrincipal) principal").
                              Now, that you have disabled the UserDatabaseRealm, you can't deploy to /manager/text with ant any more. So enable it again for the "manager"-servlet by adding the old realm definition to Tomcat 7.0\webapps\manager\META-INF\context.xml, which takes precedence over the more generally server.xml setting.

                              Also add your Tomcat server to Eclipse, so that you can configure it from there. I had to use Eclipse Juno, because it seems to have a newer WTP plug-in than Indigo. It is important that you set "Use Tomcat installation (takes control of Tomcat installation)" in the plug-in. For me, this option wasn't enabled always, so just try and click. It seems that the plug-in is a bit buggy.

                              4) Switch Apache logging to log4j. I think I didn't see SmartGWT and Tomcat logs both before, but I'm not sure. The setup is easy and is explained here:

                              With this, which took me about 1.5 days to figure out, you have an app with plain html-login and SmartGWT styled re-login form in case of session-timeout (set server.xml session-timeout to 1 minute during dev to see the form).

                              My next steps are:
                              1) Style plain login, perhaps making it dynamic to pre-fetch the compiled JavaScript (the filenames do always change)
                              2) Think about a solution to the fact that Tomcat j_security_check only offers 1-time password hashing with md-5 or sha-1 and without a salt, which obviously isn't enough. Easiest would be to hash the given pass 999 times in JavaScript before it is send to j_security_check and store it hashed 1000 times. It is also possible to include a (static) salt then.

                              I hope this helps everyone trying to set up something similar.

                              Best regards,
                              Last edited by Blama; 21 Aug 2012, 03:58.