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.
Related
We are having some difficulty when adding basic authentication to Solr 8.6.1. We are following this document, and we have created security.json file, which is successful (since Solr instance will ask userId and password when it starts.) Our difficulty happens when trying to enable the global authentication settings: we did pass the -Dsolr.httpclient.builder.factory=org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory system property,and we also set the -Dbasicauth=username:password property as follows:
// the following is the last time of our Solr Dockerfile:
CMD ["solr-foreground", "-Dsolr.httpclient.builder.factory=org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory", "-Dbasicauth=username:secret"]
However, the calls to retrieve data from Solr all come back with Error 401 require authentication.
Could someone please kindly let us know what did we miss?
You'll have to set the correct options on the client - not on the server. This is a setting that affects how the client that connects to Solr authenticates.
So when running your application, give the parameter to the java command (or configure it to be the default parameter through ant/maven/gradle/etc.
Setting it on the docker container will not do anything useful.
I've installed Flowable 3.6.1 in my localhost. But when I changed the Host configuration in Tomcat folder, I found flowable-design was unable to publish app to flowable-engage.
After tens of times attempts, I found the configuration located at Tomcat/webapps/flowable-engage/WEB-INF/classes/flowable-default.properties as following:
flowable.common.app.idm-url=http://localhost:8080/flowable-work
flowable.common.app.idm-admin.user=admin
flowable.common.app.idm-admin.password=test
So, I changed admin's password here, but it was not working actually. However, I guess the file name was the problem. Then I changed the file name to flowable.properties, it was still not working.
REMEMBER: In Tomcat/webapps/ROOT/index.html, flowable told that username and password in different flowable application is independent. If you want to change admin's password, you had to know which application you are going to apply these changes.
After a long time digging, I finally found the solution to put these three configuration in Tomcat/bin/setenv.bat as following:
set "JAVA_OPTS=%JAVA_OPTS% -Dflowable.common.app.idm-url=http://<domain>/flowable-engage/ -Dflowable.modeler.app.deployment-api-url=http://<domain>/flowable-engage/app-api -Dflowable.modeler.app.undeployment-api-url=http://<domain>/flowable-engage/platform-api/app-deployments -Dflowable.common.app.idm-admin.user=admin -Dflowable.common.app.idm-admin.password=<password>"
And these properties are loaded in flowable-ui-design-conf module, look
at
com.flowable.design.conf.ApplicationConfiguration#basicHttpClientProvider(FlowableCommonAppProperties commonAppProperties) for more information.
Cause I want my flowable-design to be able to deploy app to flowable-engage, so I changed admin's password in flowable-engage.
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>
I am attempting to use the cpanel api2 to modify the zone file for one of the cpanel accounts. Below is the code I'm executing.
$xmlapi = new xmlapi($ip);
$xmlapi->set_host("192.168.1.1");
$xmlapi->set_port("2087");
$xmlapi->set_protocol('https');
$xmlapi->password_auth($cpusername,$cpuserpwd);
$xmlapi->hash_auth("root",$root_hash);
#print_r ($xmlapi);
$xmlapi->set_output("json");
$xmlapi->set_debug(1);
$xmlapi->api2_query($cpaccount, "ZoneEdit", "add_zone_record" , array($domain, $subdomain, $type, $ipaddr, $ttl));
The commented code authenticates using the system hash. The other using password authentication. I get the same error on both authentication methods.
When I set the user id and account to root, I get an internal 500 error:
Internal Server Error 500
Could not setuid to root at /usr/local/cpanel/Whostmgr/XMLUI/cPanel.pm line 82.
If I change the userid and the account that the zone file is for, I get the message:
{
"cpanelresult":{
"apiversion":2,
"func":"add_zone_record",
"data":[{
"result":{
"status":0,
"statusmsg":"You do not have permission to read the zone for : "
}
}],
"event":{
"result":1
},
"module":"ZoneEdit"
}
}
I'm stumped on what do next. When I login at the command line as one of the non-root accounts, I can su to root once I enter the root password.
Any assistance would be appreciated.
To close this out. With no solution in site, ended up writing a php script to generate the zone file from scratch with appropriate SOA serial number management, and scheduling a cron job to run as root to replace the zone file and reload it.
Put another way, never got the Cpanel interface to work so write it from scratch.
And if anyone is curious about the final generalized implementation, it is the smartDNS feature on my website and described in the blog.
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?