-
1. Re: Multiple Domain Quesiton
fhh Apr 6, 2007 10:25 AM (in response to rjstanford)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
rjstanford Apr 6, 2007 10:37 AM (in response to rjstanford)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
fhh Apr 6, 2007 10:45 AM (in response to rjstanford)
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
rjstanford Apr 6, 2007 11:59 AM (in response to rjstanford)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
rjstanford Apr 6, 2007 12:10 PM (in response to rjstanford)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
fhh Apr 6, 2007 2:13 PM (in response to rjstanford)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
rjstanford Apr 6, 2007 2:29 PM (in response to rjstanford)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 Apr 6, 2007 3:28 PM (in response to rjstanford)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
rjstanford Apr 6, 2007 4:39 PM (in response to rjstanford)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 Apr 6, 2007 5:49 PM (in response to rjstanford)"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 Apr 6, 2007 6:31 PM (in response to rjstanford)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 Apr 6, 2007 9:55 PM (in response to rjstanford)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
fhh Apr 7, 2007 9:18 AM (in response to rjstanford)
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 Apr 7, 2007 11:28 AM (in response to rjstanford)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.