I would like to extend Liferay 6.1 session, I thought about dialog showing up when session is about to expire or something like that. I know that Liferay has something similar, I can set f.e.
session.timeout.warning = 5
And when it would be 5 minutes to expire session there would be a message and a button to extend session for another 5 minutes.
Now, the question is : Is it possible to change the extending value (instead of 5 minutes I would like to extend it to 30 min) but still I want warning message to be shown 5 minutes before expiration ?
edit : Not sure it really matters, I'm using Liferay 6.1
UPDATE
In the end it turned out that Rushikesh was right all along. There is a bug in Liferay 6.1.1 which causes showing incorrect message about extending session by timeout.session.warning value instead of timeout.session. It was fixed in Liferay 6.1.3, see here
You can certainly extend Liferay session, and also show session expiry warning, but not by just using session.timeout.warning = 5 property.
Liferay's session timeout is 30 minutes by default, which is controlled through its web.xml file.
As described here, portal-ext.properties file has below settings for configuring session timeout warning. They are solely for the javascript that pops up the session timeout warning message on the top:
#
# Specify the number of minutes before a session expires. This value is
# always overridden by the value set in web.xml.
#
session.timeout=30
#
# Specify the number of minutes before a warning is sent to the user
# informing the user of the session expiration. Specify 0 to disable any
# warnings.
#
session.timeout.warning=5
When a user clicks on 'Extend' button on the warning message, Lifeary's session is extended by 'session-timout' value (e.g. 30 minutes in this case).
HTH!
Related
is it possible to extend time when Liferay's Sesssion Messages (and Session Errors) are displayed on the page ? Normally it lasts like 8 seconds and it's not enough for me.
I use Liferay 6.1.1.
What king of message are you speaking about?
If you (example) add your message in SessionMessages...
SessionMessages.add(actionRequest, "request_processed", "this-is-my-custom-success-message")
...and show it usign taglib inside your JSP
<liferay-ui:success />
It should appear in a green-backgrounded div, with success icon (for SessionErrors it is analogous).
They should not disappear.
Please, let me know more about...
we want to navigate in Liferay to an other portlet after receiving a IPC-Event.
So we send the event from one portlet, implemented an second Portlet extends from MVCPortlet, and receive the event with some information!
So we want to navigate in Liferay to the second portlet.
The methode were we receive the event is this
#ProcessEvent(qname = "{http://liferay.com}empinfo")
public void handleProcessempinfoEvent(final javax.portlet.EventRequest request, final javax.portlet.EventResponse response) throws javax.portlet.PortletException, java.io.IOException
Also we override the methods from com.liferay.util.bridges.mvc.MVCPortlet but no one was called after sending the event.
Is there any way to navigate inside liferay (6.1.2)?
Thx Tim
Is the event handled at all? What do you mean with "navigate to the second portlet"?. Events - by default - only get distributed to the portlets that appear on the same page. If you want to receive an event on a portlet that exists on a different page, you'll have to explicitly configure Liferay to distribute events to all pages in the same site. Note that this might dig into your performance. Also - once you navigate to another page - by default the portlet's state on that page is being reset.
Check the following (and related) portal.properties:
#
# Set this property to specify how events are distributed. If the value is
# "layout-set", then events will be distributed to all portlets contained in
# a layout set. If the value is "layout", then events will be distributed to
# all portlets that are present in a layout.
#
portlet.event.distribution=layout
#
# Set this property to specify how public render parameters are distributed.
# If the value is "layout-set", then public render parameters will be
# distributed to all portlets contained in a layout set. This will only work
# correctly if the property "layout.default.p_l_reset" is set to false. If
# the value is "layout", then public render parameters will be distributed
# to all portlets that are present in a layout.
#
portlet.public.render.parameter.distribution=layout
#
# Set the default value for the "p_l_reset" parameter. If set to true,
# render parameters are cleared when different pages are hit. This is not
# the behavior promoted by the portlet specification, but is the one that
# most end users seem to prefer.
#
layout.default.p_l_reset=true
If you intend to navigate to a different page, you'll also have to note that this is not covered by the portlet API. Thus you'll have to identify how to find the relevant page, its URL and how to redirect. It's probably easier to have some more logic in the action-handling portlet and do the redirect there: At least you'll only handle one action. Potentially there might be several Events handled per Action - thus it's undefined which potential redirect will be triggered if they conflict. I'd see a real redirect (any way) as rather unexpected behavior if it comes from an EventHandler, but somewhat understandable from an ActionHandler.
This question already has an answer here:
Sign Out link in the session inactivity pop up
(1 answer)
Closed 9 years ago.
I want to manipulate the inactivity session timeout in the warning pop up in liferay
but not sure how to do that. I'm new to liferay so seeking your help.
Thanks,
Sourav
I think you want to know where to update the time after which pop up appears in Liferay when being idle.
# Specify the number of minutes before a warning is sent to the user
# informing the user of the session expiration. Specify 0 to disable any
# warnings.
#
session.timeout.warning=1
You can override the above value in your portal-ext.properties and set to 0 if you don't want to get the warning pop up.
Not related to your question : The place where this check happens is in ..deploy/ROOT.war/html/common/themes -> session_timeout.jspf page in Liferay 6.0
You can set the session-timeout interval in ..deploy/ROOT.war/WEB-INF/web.xml file.
Below is where you need to change,
<session-config>
<session-timeout>30</session-timeout>
</session-config>
This indicates that after 30 minutes if User is inactive then your session will get destroyed.
I'm using the inputRichText component for composing HTML-formatted messages in a system I'm working on.
I've encountered a problem, however. It seems the session times out, even when the user is working in the editor.
I tried setting the session timeout parameter in web.xml to 1 minute and started typing in the editor. After 1 minute the "User session expired" dialog box appeared. Is there any way to make the rich text editor component keep the session alive? It's pretty annoying to work on something for a while only to loose it to a session time out, event though you haven't been inactive.
This is the code I use to display the component in the page:
<ice:inputRichText height="250" toolbar="MyToolbar" customConfigPath="/FCKconfig.js" id="messageBody" value="#{bean.messageBody}" language="sv" saveOnSubmit="true" />
Thanks!
Edit:
I solved it using a periodic JavaScript calling into a servlet implementing the stuff outlined in this IceFaces JIRA report
If there's a better way, please let me know :)
I solved it using a periodic JavaScript calling into a servlet implementing the stuff outlined in this IceFaces JIRA report.
It basically allows a servlet to "touch" the session and hence keep it alive.
If there's a better way, please let me know :)
I have one page that does something and when the user clicks a button, the user is redirected to another page and a message is displayed. Here is my code:
public String confirm() {
FacesContext context = FacesContext.getCurrentInstance();
Flash flash = context.getExternalContext().getFlash();
flash.setKeepMessages(true);
FacesMessage msg = new FacesMessage("Succesful", "Release is confirmed!");
context.addMessage(null, msg);
return "/prot/expert/releases?faces-redirect=true";
}
I use a p:growl component which displays my message on the "releases" page. So far so good.
But then on any subsequent page that has p:growl (or if I go to another page and go back) the message is displayed again and again and I can't kill it.
I tried something like:
<c:set target="#{flash}" property="keepMessages" value="false" />
on the page that has the p:growl, I tried clearing the flash from the backing bean etc.
The message is retained and displayed all over again. If I remove flash.setKeepMessages(true); from the code above then nothing is displayed.
What am I doing wrong?
I did get the exact same problem on JBoss AS 6 with both Mojarra 2.0.3 and Mojarra 2.1.1. The flash should survive only one redirect, but in practice it not always does.
In an action method I have basically the same code:
// [add global faces message]
FacesContext.getCurrentInstance().getExternalContext().getFlash().setKeepMessages(true);
return "/someView.xhtml?faces-redirect=true";
I've been seeing three symptoms of the problem:
After doing a postback on someView, the flash faces message keeps being displayed
After a clean request to a completely different page, the face message is also displayed
After going again through the code that adds the faces message, you'll get two of the same messages on someView
Issue 2 can be explained by realizing that the flash scope is cookie based (at least in Mojarra). Relatively few people seem to understand the inherent problem with that. I've found this related question, but it has no answers: Is Flash scope free of race conditions?
Also, when trying to reproduce the problem I've got approximately a 2/3 chance of actually reproducing it. Sometimes it indeed only survives a single redirect, sometimes it's gone after a few refreshes (time based or so?) and sometimes it just sticks around and the only way to get rid of it is restarting my server(!).
Maybe I'm doing something wrong somewhere?
Observing the cookies being set, I noticed the followed:
After initially triggering the action that does the redirect:
POST Response
Set-Cookie csfcfc=_50Xfr
GET Response
Set-Cookie csfcfc=50Xfn_51Xfn
The thing to notice here is that the response from the GET request for the redirect again sets a cookie. You want think that for a flash scope the cookie would need to be deleted here.
If I submit a form on the view towards I'm redirected, the following happens:
POST Response
Set-Cookie csfcfc=_50Xfn
The message is now gone.
However, when I submit the form once more, the following happens:
POST Response
Set-Cookie csfcfc=_52Xfn
And, the message is back :(
If I again submit the form:
POST Response
There is no more Set-Cookie header and the message in once again gone. If I continue submitting the form, the last cookie (csfcfc=_52Xfn) keeps being send to the server, but there are no more new cookies being set and no messages are displayed.
Edit:
During debugging I came across a critical section in ELFlash.java (Mojarra 2.0.3):
void saveAllMessages(FacesContext context) {
// take no action on the GET that comes after a REDIRECT
Map<Object, Object> contextMap = context.getAttributes();
PreviousNextFlashInfoManager flashManager;
if (null == (flashManager = getCurrentFlashManager(contextMap, true))) {
return;
}
if (flashManager.getPreviousRequestFlashInfo().isIsRedirect()) {
return;
}
}
During the context of the GET request following the redirect, one would suppose isIsRedirect would return true, but it returned false. This could be a local problem, that I'm going to investigate further.
Interesting to note is perhaps that the cookie values actually have some meaning, according to the following:
FirstTimeThru("f"),
SecondTimeThru("s"),
IsRedirect("r"),
IsNormal("n");
So the first cookie (_50Xfr), is a FirstTimeThru and a IsRedirect.
Your concrete problem is caused by a bug in older Mojarra versions, specifically issue 1751. There have however been many issue reports for the flash scope afterwards. The flash scope is in older Mojarra versions known for the following major problems:
issue 1751 - Flash scoped messages lives longer than next request - fixed in 2.0.7 / 2.1.4
issue 2126 - Flash cookie enables data exploits - fixed in 2.1.24 / 2.2.1
issue 2136 - Flash cookie not available when redirected to different path - fixed in 2.1.14 / 2.2.0
issue 2902 - Flash cookie uses wrong path for applications on root - fixed in 2.1.24 / 2.2.1
issue 2955 - Flash creates sometimes version1 cookies which fails in IE<=10 - fixed in 2.1.25 / 2.2.2
issue 2973 - Flash causes NPE on stale cookies after a session expire - fixed in 2.1.25 / 2.2.2
issue 2862 - Flash cookie not cleared when stale - fixed in 2.1.27 / 2.2.5
All in all, concluded can be that you'd need to upgrade to a minimum of Mojarra 2.1.27 / 2.2.5 (due date 2 january 2014) in order to get rid of all those problems.
Try setting property redisplay to false:
<p:growl redisplay="false"/>