Back when we were running the regular Apereo CAS, there was a setting for login session timeouts, so that if someone went to the CAS login screen and just let it sit, the login session would timeout after a certain period of time (5-10 minutes IIRC.)
I was curious if there was a similar configuration settings with WSO2, and if so, what parameter it is?
The reason I'm asking is because on Saturday we did our first round of incoming student registrations, and apparently the Admissions folks logged in all of the lab computers and got them to the login screen about an hour before the students went to use them, and no one could log in until they refreshed their browsers. So I'm expecting that there is a setting for that somehow, I'm just not sure which setting it would be. Just looking at the identity.xml file, there are quite a few configurable timeout settings, and I'm not sure if it's even one of these:
...../repository/conf/identity # cat identity.xml | grep -i timeout
<CleanUpTimeout>720</CleanUpTimeout>
<CleanUpTimeout>2</CleanUpTimeout>
<SessionIdleTimeout>720</SessionIdleTimeout>
<RememberMeTimeout>10080</RememberMeTimeout>
<AppInfoCacheTimeout>-1</AppInfoCacheTimeout>
<AuthorizationGrantCacheTimeout>-1</AuthorizationGrantCacheTimeout>
<SessionDataCacheTimeout>-1</SessionDataCacheTimeout>
<ClaimCacheTimeout>-1</ClaimCacheTimeout>
<PersistanceCacheTimeout>157680000</PersistanceCacheTimeout>
<SessionIndexCacheTimeout>157680000</SessionIndexCacheTimeout>
<ClientTimeout>10000</ClientTimeout>
<!--<Cache name="AppAuthFrameworkSessionContextCache" enable="false" timeout="1" capacity="5000"/>-->
<CacheTimeout>120</CacheTimeout>
The global configuration can be found in the < IS_HOME >/repository/conf/identity/identity.xml file under the < TimeConfig >element.
<TimeConfig>
<SessionIdleTimeout>15</SessionIdleTimeout>
<RememberMeTimeout>20160</RememberMeTimeout>
</TimeConfig>
More information can be found here.
mgt console session timeout: Open repository/conf/tomcat/carbon/WEB-INF/web.xml Increase the session-timeout value.
<session-config>
<session-timeout>240</session-timeout>
<cookie-config>
<secure>true</secure>
</cookie-config>
</session-config>
Related
I enabled user authentication on Node Red. but when I restart the service the user is still logged in
I have done some searches. there is some suggestions around changing the machine key every time the service restarts.
does anyone have any suggestions about what exactly should I do ?
As mentioned in the docs on securing Node-RED the authentication tokens generated last for 7 days.
You can change this by editing the settings.js file
The expiration time can be customised by setting the sessionExpiryTime
property of the adminAuth setting. This defines, in seconds, how long
a token is valid for. For example, to set the tokens to expire after 1
day:
adminAuth: {
sessionExpiryTime: 86400,
...
}
EDIT:
The session tokens on the backend are (when using the default storage plugin) stored in a file called .sessions.json in the userDir (as logged on startup). If you want to log out all users on a restart then you will need to delete this file before starting Node-RED.
Without getting into much detailed code
I have an 'kiosk' application that is running in about 500-800 different 'kiosk' at about 50 locations. Very simple application that connects to internet via a Verizon MIFI (2-3 MIFI per location). We believe that Verizon has made some changes to the network and now randomly I get
The request failed with HTTP status 417: Expectation failed
I have viewed The request failed with HTTP status 417: Expectation Failed - Using Web Services
and FB Connect: (417) Expectation failed
But you see I already had used
System.Net.ServicePointManager.Expect100Continue = false
in my code.
So one of the issues I have is the application isn't easy to test, and it will fail for 20-30 minutes or several days, then clears itself up.
Changing the config to include
<system.net>
<settings>
<servicePointManager expect100Continue="false" />
</settings>
Would be a large task, I don't know it that would even fix it. Since it is random I'm having troubles because I typically can't get it to fail in my office at my desk more than 1 time.
I happen to use VB and .Net for the application and services that run with the 'kiosk'.
The issue seems to be with the config on the mifi and not the Verizon network itself. We recently switched APNs and when a mifi connects to the Verizon network it is supposed to update automatically. Sometimes the mifi will fail to update the APN setting and that is when we get this error message. There are two ways I have found to fix this issue. The first and easier is to log into the mifi and manually update the setting. If you are dealing with a user who is not tech savvy and walking them through logging into the mifi will not work you can call the Verizon wireless enterprise help desk and have them remove the feature set from the mifi, add the features back, and then pull the battery from the mifi and power cycle it, this will make the mifi request the configuration settings again.
I recently implemented Fine Uploader and it's been mostly successful. A few users are however are not able to upload. They are all using modern browsers (IE10, FF and Chrome). One let me remotely access their machine and I was able to try it on both Chrome and FF.
I got the same error on both:
[10:45:28.330] "[FineUploader 3.8.0] Received response status 403 with body: <?xml version="1.0" encoding="UTF-8"?>
<Error><Code>AccessDenied</Code><Message>Invalid according to Policy: Policy expired.</Message><RequestId>--removed--</RequestId><HostId>--removed--</HostId></Error>"
Is it something with the timezone settings on their computer where it's generating an invalid policy?
The timezone settings will have no effect as times are UTC. However, if the time on the user's computer is not accurate (say, off by 5 or more minutes), then the policy will be expired, according to Amazon.
Fine Uploader sets an expiration date to 5 minutes (again, in UTC). The date used is generated in the browser, so your client machine's time will be used. If the client machine's clock is slow by 5 or more minutes, the policy will be seen as expired when Amazon handles it.
I'm fairly sure that the issue is due to a significant drift on your customer's machine clock. If you verify this, I suggest you instruct them to keep system clock synced with a time server.
Update: A new feature was added to Fine Uploader 5.5 that allows you to overcome extreme clock drift on user machines/browsers. See the clock drift section on the S3 feature page for more information.
For my web app, I use tomcat declarative security to tie login credentials to the company Active Directory. On two of our servers, logins were timing out after one minute of inactivity. On the other two servers, there is a thirty minute timeout (which is what I want).
Yeseterday, I found the cause of the problem. The two servers with one minute timeouts have a tomcat Persistence Manager enabled to write session information to disk. Our IT guy is out this week, so I don't know the exact details of what he was trying to accomplish with this, but he had set PersistenceManager up like this in context.xml:
<Manager sessionIdLength="64" className="org.apache.catalina.session.PersistentManager"
maxIdleBackup="10" maxIdleSwap="30">
<Store className="org.apache.catalina.session.JDBCStore" dataSourceName="jdbc/Auth"
sessionTable="sessions" sessionAppCol="app_name" sessionDataCol="session_data" sessionIdCol="session_id"
sessionLastAccessedCol="last_access" sessionMaxInactiveCol="max_inactive" sessionValidCol="valid_session" />
</Manager>
I did some research and discovered that the Idle numbers are in seconds. Thinking that might be the culprit I changed the Manager portion to:
<Manager sessionIdLength="16" className="org.apache.catalina.session.PersistentManager"
maxIdleBackup="600" maxIdleSwap="3600" minIdleSwap="1800">
This fixed my problem. So it appears that forcing the Persistence Manager to write sessions out to disk after thirty seconds of inactivity was killing my session logins. I tracked the JSESSIONID cookie and found that the cookie remained the same even after the user is forced back to the login screen. It only changes when you re-login. This is what you would expect, because persisting the session to disk couldn't possibly change the session id. However, it does cause my declarative security model to force the user to log in again.
I did find in the manual that the maxIdleSwap variable not only controls persisting sessions to disk, but also causes the "passivating of the session out of server memory". This sounds a bit suspicious to me.
Does anyone have any experience with this issue? Why does the Persistence Manager kill my web app logins when it persists sessions to disk? Is there any way around this without changing the swap control variables like I did?
I am working on session replication with two server instances in a cluster.
Session id is not getting replicated to the second server and hence it always creates a new one, and my open application gets errored out and gets closed. How to handde this failover of server instance so that the user will not be aware if the server instance is down. Here are the settings i am using in weblogic.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<session-descriptor>
<session-param>
<param-name>URLRewritingEnabled</param-name>
<param-value>true</param-value>
</session-param>
<session-param>
<param-name>PersistentStoreType</param-name>
<param-value>replicated</param-value>
</session-param>
</session-descriptor>
<context-root>#CONTEXT_ROOT#</context-root>
</weblogic-web-app>
Now that you know that going to the app server directly does not alleviate appear to alleviate your session id issue, you need to do deeper debugging:
Install Firebug in Firefox (https://getfirebug.com/)
Go to your website in Firefox
Turn on Firebug in Firefox (and make sure that the Firefox's Net tab, which might be grayed-out, is enabled)
Log in to your website
Look at the Net tab in firebug and expand the plus sign for the request.
Look at the Request Headers section -- Do you see anything in the cookie field that looks like the JSESSIONID? If so, does the JSESSIONID stay the same or does it change when you navigate to other pages on your site?
I'm attaching a screenshot of using Firebug to look at the cookie that gets set and re-sent on every request when you have logged in to the weblogic admin console for comparison (rather than ADMINCONSOLESESSION, you'd see JSESSIONID as the cookie key)