1 2 Previous Next 17 Replies Latest reply on Apr 9, 2007 6:37 AM by fhh

    Multiple Domain Quesiton

      I should preface this by saying that I'm very familiar with Struts, somewhat with Spring, but new to Seam and full-fledged EJB apps in general. So this may be a stupid question, but I can't find a good answer anywhere (probably searching on the wrong stuff). Anyway...

      I'm modelling a new application, and I really want to use Seam for it. I think that after a week or two of fooling with it so far I'm already more productive than I was in Spring when I started, and that's saying something. Here's the deal. I need to be able to provide different functionality, and different content, based on the domain portion of the URL, and I'm not sure what the best, "SEAMiest" way to do that would be.

      Normally, I'd just use a filter. That doesn't seem to fit well with the paradigm here.

      You can think of the app as something like Typepad. Its not, but that's a close enough approximation for this discussion. There's a central application that's used for configuration and content creation, then the app can be accessed through a ton of different customer domains and should serve up specific content. For cluster cache reasons, I really want this to be a single app.

      Now, I'm new to EARs in general. Should this be done as two separate WAR applications? Or can I just do one large app with some redirection logic somewhere? Any advice is welcomed, and thanks.

      -Richard

      ps: Cool product, guys. Seam really rocks.

        • 1. Re: Multiple Domain Quesiton

          Add this to components.xml:

          <factory name="hostname" value="#{facesContext.externalContext.request.servername}" scope="<APPROPRIATE_SCOPE>"/>
          

          (This is from memory. Check javadoc.).

          Then you can use hostname in el expressions with facelets:

          <c:if test="#{hostname == 'www.mydomain.com'">
          blah
          </c:dif>
          


          Or you can inject the hostname into your components:
          @Name("test)
          pulic class test {
          
           @In private String hostname;
          
          // getters and setters
          
          }
          


          Regards

          Felix



          • 2. Re: Multiple Domain Quesiton

            Very cool, and thanks for the response. Would it be appropriate to use security rules to send 404s if someone tried to access one of the "control" domain pages through a non-control hostname? Or would that be a perversion of the security system and there's a much easier way to do it? I don't want to give any hint that the control app exists to people using the data-view path.

            Again, thanks - I'm trying to come up with best practice designs that not only work, but work with the elegance I've become used to with this project.

            • 3. Re: Multiple Domain Quesiton

               


              Would it be appropriate to use security rules to send 404s if someone tried to access one of the "control" domain pages through a non-control hostname? Or would that be a perversion of the security system?


              Yes, it would be a perversion of the security system. It would be "security through obscurity" - and even rather poor at that. Security should NEVER depend on false error messages and something as fragile as DNS. Use secure name/passwords instead.

              Regards

              Felix

              • 4. Re: Multiple Domain Quesiton

                I agree - let me explain myself a little better. With this setup, there's effectively one control application that contains a large number of potentially useful URLs. The display sites, generated by the same app, contain a much smaller list of URLs.

                When a non-control user (who doesn't even know that the control site exists) visits a random URL, ie: "http://theirsite.com/foo", they receive a 404 error. If they visit a URL that on the control site (ie: http://control.com/admin), that will return them an error message saying that they're not logged in - standard security practice. If they visit "http://theirsite.com/admin") though, even though to the app its a legitimate endpoint, I wish to present them with a 404 error since its not known to their URL.

                One way to do this would be to have a test in the SecurityException (or however Seam security is best implemented) that normally redirects to the login page that consumes the exception and rethrows a page not found exception. That doesn't seem particularly "correct", per se, so I was curious as to whether there was a known, better solution.

                Its not going to be quite as messy as it sounds, by the way - all of the domains will have the same structure as far as pages existing or not existing, with the exception of the "control" domain.

                • 5. Re: Multiple Domain Quesiton

                  One more clarification - I realize that this problem would disappear if I had one application servicing all of the (multiple-hostname) contant requests, and a totally separate application handling the administrative tasks. But from my reading of the Seam/J2EE docs that would mean that I'd lose the ability to use a lot of the caching capabilities, since they'd be sharing through the database. If this isn't the case - if I can set up two different WAR files that share the Hibernate/Seam cache and bind one of them to a single hostname and the other to "all other" hostnames - that would be ideal.

                  The deployment environment is a JBoss cluster if that makes a difference.

                  • 6. Re: Multiple Domain Quesiton

                    Is the access to the _admin_ pages high volume?

                    Regards

                    Felix

                    BTW.: I think caching should alaways be a last effort to improve scalabilty. I would start with minimizing database access.

                    • 7. Re: Multiple Domain Quesiton

                      Felix,

                      No, not terribly high volume. However, the non-admin pages are high volume. The reason that I want cache visibility (preferably using the transparent entity bean caching, not actually using pojoCache directly) is that updates made to the database through the control side should be immediately visible on to the rest of the users.

                      In the past, I've had cache issues that have basically limited me to either pushing all data through the same app, or turning off most of the caching possibilities. The Seam documentation talked at some length about the "rich, multi-layered caching strategy" integrating between the EJB layer, the standard hibernate cache, the conversational cache, impacts on clustering, et cetera, and it seemed to be saying that you got all of that "for free," if you had all data access through the cache, but it sounded more complicated if a 3rd party had to control selective cache expiration.

                      BTW, I agree with your cache comment - I've sped up more than a few apps by removing all custom caching logic completely and just letting the DB do its thing - but that's why I was interested in the idea that if you did everything "The Seam Way" that you got a whole stack of intelligent caching effectively for free, managed completely by the container and framework.

                      Or am I simply reading too much into the caching language, and I'll be just fine? I thought that would at least invalidate Hibernate's potential use of the 2nd level cache. Which might still be okay for the app, but I'm interested in making sure that this is pretty solidly scalable.

                      • 8. Re: Multiple Domain Quesiton
                        pmuir

                        Using the Seam security to restrict access to admin dependent on domain is probably overkill. You could easily do it with a page action

                        <page view-id="/admin/*" action="#{pageController.restrictAdminAccess}" />


                        @Name("pageController")
                        public class PageController {
                        
                         @In String hostname;
                        
                         public String restrictAdminAccess() {
                         if (ALLOWED_HOSTNAME.equals(hostname)) {
                         return null;
                         } else {
                         return "/error.xhtml";
                         }
                         }
                        }


                        Where error.xhtml would be a page with a message telling the user that page isn't accessible (of course you could send a 404 at this point using FacesContext

                        • 9. Re: Multiple Domain Quesiton

                          Great - that looks like exactly what I was needing. So really I can use actions to replace a lot of what I was using filters to do before. Very cool, and very much the "Seam" way of doing business. Thanks a ton!

                          • 10. Re: Multiple Domain Quesiton
                            spambob

                             

                            "rjstanford" wrote:
                            ...If they visit "http://theirsite.com/admin") though, even though to the app its a legitimate endpoint, I wish to present them with a 404 error since its not known to their URL...


                            I was thinking about how to do this best too for some time and I really think this is useful, not "security by obscurity", because people wont start to fiddle with something if they don't know it's there.
                            More generally speaking: I would like to overwrite the standard reaction upon an exception for a specific subset of a pages.

                            Further I would prefer to do this integrated with Seam security & fully configured in pages.xml instead of manually checking for it like Peter described.

                            So could we please get something like:
                            <page view-id="/admin/*">
                             <restrict>#{s:hasRole('admin')}</restrict>
                             <exception class="org.jboss.seam.security.AuthorizationException">
                             <http-error error-code="404"/>
                             </exception>
                            </page>

                            One downside might be that one would get a 404 too if one is admin but calls some method that requires "superadmin" privileges. On the other hand - if the app is designed in an coherent way - this shouldn't happen because controls for which one hasn't the necessary privileges are usually not shown. Another solution might be to overwrite the exception mapping only for page access and not for the backend.

                            So what do you think about this & could this please be added?!

                            • 11. Re: Multiple Domain Quesiton
                              pmuir

                              I think http://jira.jboss.com/jira/browse/JBSEAM-769 is what you are after?

                              Your syntax looks fine to me, someone just needs to implement it :) Patches welcome!

                              • 12. Re: Multiple Domain Quesiton
                                spambob

                                Thank you very much for your response Peter!

                                In fact http://jira.jboss.com/jira/browse/JBSEAM-769 seems to be exactly what I want but unfortunately I'm not this deep into Seams inner mechanics (in fact I don't have the slightest bit of an idea how this is implemented internally) - and I'm drowning in work (who's not).

                                So I probably won't have time (or the knowledge) to fix it myself but instead I hope for some brighter minds than myself to implement this ;).

                                Regardless of the above I'm not really sure what would be the best way to implement this because the reason for this request is only to "obfuscate" / redirect upon an (Authorization)Exception upon a view request (so the AuthorizationExceptions created while handling the already allowed view request are handled like they are now - like they would be handled without this addition).

                                What do you think about this (especially about overwriting the exception mapping only for page requests / views and not the internal execution) - and how much work would this change require (just a raw guess)?

                                PS: I sign your request to be able to overwrite exception mapping but regarding this subject it might be more than needed / wanted.

                                • 13. Re: Multiple Domain Quesiton

                                   


                                  I was thinking about how to do this best too for some time and I really think this is useful, not "security by obscurity", because people wont start to fiddle with something if they don't know it's there.


                                  Sorry, but this is the definition of security by obscurity. Access to restricted pages should be secure especially if people start "fiddling" with them.

                                  I'm not sure if you are aware of the fact that the hostname I use to reach your machine is entirely under my control. I can just add whatever I want to my /etc/hosts and I will see those pages.

                                  And once you are using this as a security mechanism you will accidently rely on this because after a test on your setup it "looks" secure.

                                  So in my opinion your security approach is like aiming the loadded shotgun at your foot and taking the safety off. You only have to wait a bit before it goes off.

                                  Regards

                                  Felix

                                  • 14. Re: Multiple Domain Quesiton
                                    spambob

                                    Lolz, you misunderstood me! I don't have the intention to build a security model relying on the http referrer or similar stuff instead of seams security model. I just want to send different responses for security exceptions depending on the view id that is accessed.

                                    E.g. I normally would redirect to some page showing the proper message - "You don't have the necessary rights", "Please login", ... But for a part of my site - e.g. /admin/* - I would like to return only a 404 if the user isn't logged in or isn't in the role 'admin'. This way normal users can't prove that /admin exists and wont start fiddling with it.

                                    I hope it's clearer now ;) - anyway: thanks for the warning.

                                    1 2 Previous Next