[JBoss JIRA] Created: (SEAMSECURITY-12) Introduce session management into Seam Security
by Shane Bryzak (JIRA)
Introduce session management into Seam Security
-----------------------------------------------
Key: SEAMSECURITY-12
URL: https://jira.jboss.org/browse/SEAMSECURITY-12
Project: Seam Security
Issue Type: Feature Request
Reporter: Shane Bryzak
Assignee: Shane Bryzak
Fix For: 3.0.0.Beta1
A feature in which many of our users have expressed interest in the past, session management would provide an application-scoped registry of all active user sessions. We should provide features for terminating selected user sessions, setting a policy for multiple user sessions (one/multiple session per user) and provide some kind of formal support for session logging (last login time, ip address, etc). Up till now we've told our users to implement all this stuff manually, but I think it would be cool if we provided support for it out of the box.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (JBSEAM-4577) Seam Mail looks up template in wrong context on tomcat with shared seam
by Vasilii Lukoyanov (JIRA)
Seam Mail looks up template in wrong context on tomcat with shared seam
------------------------------------------------------------------------
Key: JBSEAM-4577
URL: https://jira.jboss.org/jira/browse/JBSEAM-4577
Project: Seam
Issue Type: Bug
Components: Mail
Affects Versions: 2.2.0.GA
Environment: Tomcat 6.0.18, Seam 2.2.0.GA (shared)
Reporter: Vasilii Lukoyanov
Assignee: Pete Muir
I've got Tomcat with Seam jars shared among all projects (shared.loader=${catalina.base}/shared/seam/*.jar in catalina.properties). Each app has it's own vhost, and deployed to ROOT context.
Layout is the following:
vhosts/siteA.com/ROOT
vhosts/siteB.com/ROOT
Seam application on siteB.com uses seam mail to send confirmation emails. But when it tries to send a message (template is /layout/1email.xhtml)
the following exception is thrown:
javax.servlet.ServletException: #{mailer.sendPreActivationEmail}: java.lang.IllegalArgumentException: resource doesn't exist: /layout/1email.xhtml
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:277)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:164)
at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:141)
at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:90)
at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:406)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:368)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:495)
at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:419)
at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:378)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.faces.FacesException: #{mailer.sendPreActivationEmail}: java.lang.IllegalArgumentException: resource doesn't exist: /layout/1email.xhtml
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118)
at javax.faces.component.UICommand.broadcast(UICommand.java:387)
at org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:321)
at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:296)
at org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:253)
at org.ajax4jsf.component.AjaxViewRoot.processApplication(AjaxViewRoot.java:466)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
... 39 more
After some investigation I tried to put message template /layout/1email.xhtml into siteA.com context (vhosts/siteA.com/ROOT). After that I was able to send messages from siteB.com application.
Component that sends code:
@Name("mailer")
@Scope(ScopeType.CONVERSATION)
public class Mailer {
@In("renderer")
private Renderer _renderer;
public void sendPreActivationEmail(Account aUser) {
Contexts.getConversationContext().set("account", aUser);
_renderer.render("/email/eganov_pre_activate.xhtml");
}
}
Important note: when tomcat is starting, siteA.com loads first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (JBSEAM-4664) [excel] Need ability to choose between Content-Disposition: inline and Content-Disposition: attachment for downloads
by Eric Jung (JIRA)
[excel] Need ability to choose between Content-Disposition: inline and Content-Disposition: attachment for downloads
--------------------------------------------------------------------------------------------------------------------
Key: JBSEAM-4664
URL: https://jira.jboss.org/browse/JBSEAM-4664
Project: Seam
Issue Type: Patch
Components: Excel
Affects Versions: 2.2.1.CR1, 2.2.0.GA, 2.2.0.CR1, 2.1.2.GA, 2.1.2.CR2, 2.1.2.CR1, 2.1.1.GA, 2.1.1.CR2, 2.1.1.CR1, 2.1.0.SP1, 2.1.0.GA, 2.0.3.CR1, 2.0.2.SP1, 2.0.1.GA, 2.0.0.GA, 1.2.1.GA, 1.2.0.GA, 1.1.6.GA, 1.1.5.GA, 1.1.1.GA, 1.1.0.GA, 1.0.1, 1.0, 2.2.1.CR2, 3.0.0.BETA1, The future
Reporter: Eric Jung
Attachments: UIWorkbook.java.diff
When downloading an Excel workbook, org.jboss.seam.excel.ui.UIWorkbook always sends the HTTP response header "Content-Disposition: inline; filename="xxxx.xls" where xxxx is the value of e:workbook's filename attribute.
This header causes problems on some installations of IE 6, 7, and 8 with Excel 2002. Depending on how some settings are configured in the OS, the document may never open after download.
Changing the HTTP response header value to "Content-Disposition: attachment; filename="xxxx.xls" solves the problem. Notice the only difference is the word "attachment" vs. "inline". I would like the capability to choose between these two, just like jboss-seam-pdf.jar provides the same capability with its org.jboss.seam.pdf.ui.UIDocument:
<pdf:document title="Some Title" disposition="attachment"> ... </pdf:document>
Mail attachments in Seam provide the same capability:
<m:attachment value="#{person.photo}" contentType="image/png" disposition="inline"/>
I'm attaching a patch against Seam 2.2 trunk which provides this capability. With this patch, we can now write:
<e:workbook type="jxl" disposition="attachment" ...> ... </e:workbook>
or
<e:workbook type="jxl" disposition="inline" ...> ... </e:workbook>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3355) SeamExpressionEvaluator gobbles up exceptions
by Wolfgang Schwendt (JIRA)
SeamExpressionEvaluator gobbles up exceptions
----------------------------------------------
Key: JBSEAM-3355
URL: https://jira.jboss.org/jira/browse/JBSEAM-3355
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.0.BETA1
Reporter: Wolfgang Schwendt
Priority: Critical
Rev 8710 of org.jboss.seam.bpm.SeamExpressionEvaluator introduced a serious bug. If the invocation of the method expression (me.invoke(...)) throws an exception such as org.jboss.seam.security.AuthorizationException, the SeamExpressionEvaluator afterwards tries to evaluate the EL expression as a value expression. This of course results in a second exception thrown: PropertyNotFoundException. Consequently, the list "exceptions" has size > 2 (rather than just size==1), which results in SeamExpressionEvaluator throwing an ELException that does not wrap the exception which originally caused the method expression invocation to fail.
The bug was introduced because, compared with earlier versions, the try/catch-blocks for the method expression and value expression evaluation were changed and are now wrong. This is serious because it breaks the handling of any application exception thrown while evaluating the EL method expression, such as AuthorizationException.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (SEAMCRON-15) CL issues on redeployment
by Peter Royle (JIRA)
CL issues on redeployment
-------------------------
Key: SEAMCRON-15
URL: https://issues.jboss.org/browse/SEAMCRON-15
Project: Seam Cron
Issue Type: Bug
Reporter: Peter Royle
Assignee: Peter Royle
Diablo-D3 gets it on every redeployment (from Eclipse to JBoss AS 6) and I have seen it once (using NetBeans redeploying after sitting overnight). The sumptom is the 'Singleton is not set' error.
In a conversation about this Stuart Douglas explained how I can solve this:
(04:42:51 PM) stuartdouglas: something that did just occur to me is that weld will probably not work very well in this new thread anyway, unless you set the TCCL to the correct one
(04:43:07 PM) PeteRoyle: TCCL?
(04:43:16 PM) stuartdouglas: Thread Context Class Loader
(04:43:28 PM) stuartdouglas: weld uses it a lot, even for stuff that should not need it to be set
(04:43:51 PM) stuartdouglas: so if it is not set you end up with highly informative 'Singleton is not set' errors
(04:44:30 PM) PeteRoyle: Ahah! I've been getting those sporadically on redeployment
(04:44:45 PM) PeteRoyle: But to do with scheduling, not asynch
(04:44:49 PM) PeteRoyle: (so far)
(04:45:20 PM) stuartdouglas: those are pretty much always due to the wrong class loader being set as the TCCL
(04:45:54 PM) stuartdouglas: also the only beans that will be accessible is @ApplicationScoped and @Dependant
(04:46:10 PM) stuartdouglas: unless you put in some non-portable code to set up the contexts
(04:46:11 PM) PeteRoyle: Is there a typical cure for that which doesn
(04:46:29 PM) PeteRoyle: ''t require knowledge of how classloading works?
(04:47:34 PM) stuartdouglas: not really, it depends where you get the errors, it should only be a problem when you start trying to use threads that you have spawned yourself to interact with weld
(04:48:31 PM) stuartdouglas: for @Async the solution is to set the TCCL to the same as the original threads TCCL, and set it back in a finally block
(04:49:11 PM) stuartdouglas: and it should really be run as a PriviliedAction, because a security manager might not let you set it
(04:50:22 PM) marekn [~mnovotny@nat/redhat/x-wgsrrhabedyogdbb] entered the room.
(04:50:39 PM) PeteRoyle: I get what you're saying, but I'm not sure how to do that stuff
(04:50:54 PM) PeteRoyle: (setting the TCCL and running as PrivAction)
(04:51:57 PM) stuartdouglas: https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:11 PM) stuartdouglas: https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java...
(04:52:43 PM) stuartdouglas: note that SecurityActions is package private, otherwise any class can use it to set the TCCL
(04:53:42 PM) stuartdouglas: basically it just wraps Thread.currentThread().set/getContextClassLoader
(04:54:38 PM) PeteRoyle: Should I copy this code into Cron, (or Solder) to make it portable?
(04:55:09 PM) stuartdouglas: it needs to be copied each time
(04:55:38 PM) stuartdouglas: otherwise any code can get/set the TCCL
(04:56:02 PM) kevinpollet [~kevinpoll(a)217.112.54.72] entered the room.
(04:56:56 PM) PeteRoyle: OK so do I set the TCCL as the first thing in the new thread?
(04:56:59 PM) amitev [~amitev(a)212.25.36.84] entered the room.
(04:57:06 PM) stuartdouglas: yes
(04:57:11 PM) PeteRoyle: (frm within the thread, say inside the run() method)?
(04:57:17 PM) stuartdouglas: yes
(04:57:34 PM) PeteRoyle: and unset it from a finally block from the original thread which screate the new thread
(04:57:52 PM) PeteRoyle: screate=created
(04:58:21 PM) stuartdouglas: yes, although you can just set it to null rather than saving and restoring the existing TCCL
(04:59:01 PM) stuartdouglas: otherwise if you are using a thread pool the TCCL can hang around after redeployment, which results in a memory leak
(04:59:47 PM) PeteRoyle: actually it looks like all the examples in WeldContainer do both those things in the same thread. Can I unset the TCCL at the end of the run() method (in a finally)?
(04:59:58 PM) maschmid [~maschmid@nat/redhat/x-fjnivohxvbmhnpfw] entered the room.
(05:00:00 PM) stuartdouglas: yes
(05:00:06 PM) PeteRoyle: ok
(05:00:33 PM) stuartdouglas: oops, sorry, I mis-read your earlier question
(05:00:50 PM) stuartdouglas: you should only manipulate it inside the run method
(05:00:57 PM) PeteRoyle: ok gotchya
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months