I have migrated Wildfly server from 8.0 final to 8.1 final and Apache Shiro started having problems when creating user sessions.
The exact same application runs without any problem on 8.0 final but with 8.1 users cannot establish sessions every time they log in they are redirected to the login page even though they were authenticated successfully.
I cannot figure out what has changed since 8.0 that would cause this issue.
Changing the cookie name "JSESSIONID" to something else fixed the issue.
Here how I modified my shiro config
sessionManager=org.apache.shiro.web.session.mgt.DefaultWebSessionManager
securityManager.sessionManager=$sessionManager
securityManager.sessionManager.sessionIdCookieEnabled = true
cookie = org.apache.shiro.web.servlet.SimpleCookie
cookie.name = here.pick.your.session.id
sessionManager.sessionIdCookie = $cookie
Related
I have a regression with a TCP\IP connection string post a firebird 3 migration from v2.5. The FirebirdClient version is 4.6.1 but I've tested with the latest stable version and it also doesn't work (v7.10.1).
The error message is "Your user name and password are not defined. Ask your database administrator to set up a Firebird login".
The stacktrace:
at FirebirdSql.Data.FirebirdClient.FbConnectionInternal.Connect()
at FirebirdSql.Data.FirebirdClient.FbConnectionPoolManager.Pool.GetConnection(FbConnection owner)
at FirebirdSql.Data.FirebirdClient.FbConnectionPoolManager.Get(ConnectionString connectionString, FbConnection owner)
at FirebirdSql.Data.FirebirdClient.FbConnection.Open()
The user was created via the IBExpert UI.
Here's how the connection string looks (not real life connection data obviously):
#"Database=inet://10.000.0.000:3050/C:\Database.FDB;User=MY_USER;Password=secret";
The same user works if using a standard same network connection string as below:
#dialect=3;initial catalog=C:\Database.FDB;data source=localhost;user id=MY_USER;password=secret;character set=ISO8859_1;pooling=True;connection lifetime=30;server type=Default;port number=3050
My firebird.conf is set like so:
ServerMode = Super
DefaultDbCachePages = 100K
FileSystemCacheThreshold = 100M
TempBlockSize = 2M
TempCacheLimit = 4000M
AuthServer = Legacy_Auth, Srp, Win_Sspi
AuthClient = Legacy_Auth, Srp, Win_Sspi
UserManager = Legacy_UserManager, Srp
WireCrypt = Enabled
RemoteServicePort = 3050
LockMemSize = 30M
LockHashSlots = 30011
RemoteAccess = true
Not sure what I'm missing here. The connection string above works with SYSDBA. According to the firebird documentation I've read it looks fine. I've read all other stackoverflow tickets with the same issue but don't see any answers that work for me. Any ideas?
Recent versions of FirebirdSql.Data.FirebirdClient support the version 13-15 wire protocol of Firebird 3, and then only support Srp authentication. Your old version supported only up to the v12 protocol (Firebird 2.5) and then would use the legacy authentication. If you created the user using the Legacy_UserManager (the default in your configuration), then you cannot authenticate with version 7.10.1 (where you could with 4.6.1), because as far as the Srp authentication plugin is concerned, the user does not exist.
It looks like you created the user either using gsec, which always applies the default user manager (FYI, gsec is deprecated since Firebird 3), or you used CREATE USER without USING PLUGIN Srp (or with USING PLUGIN Legacy_UserManager). You can verify this by checking the output of select sec$user_name, sec$plugin from sec$users. The solution would be to drop the user and then create it again with the right user manager (USING PLUGIN Srp).
Note that in theory you could have the user both for Srp and Legacy_UserManager (e.g. if the same user needs to be used by an application that cannot authenticate with Srp), but it is far more secure to have the user only exist for one plugin.
On a related note, the configuration you have applied is insecure. It is far more secure to leave out Legacy_Auth of the AuthServer setting or - if you still have applications that cannot apply Srp - to put it last (for both AuthServer and AuthClient). Similarly, it is recommended to put Legacy_UserManager last in UserManager (or leave it out entirely), so by default - if you use gsec, or don't include USING PLUGIN xxx in CREATE USER - it will create more secure Srp-type users.
I faced one issue when upgraded codeigniter 2.2.0 into 3.1.9
Ex : I'm set a session in page1 and then redirecting into page2. After redirect, Unable to get page1 session into page2. In page2, I printed the session is showing empty.
Page1:
$this->session->set_userdata('user', $data );
Page2:
$user = $this->session->userdata('user');
I'm not facing this issue in codeigniter 2. Only facing in Codeigniter3.
Your code is OK.
Before using session library in codeigniter you need to configure session driver and load the session library, make sure you have correct setup.
To configure session driver goto /application/config/config.php, if you are using files for session driver make sure you have read and write permission for $config['sess_save_path'] location.
You can autoload the session library by adding session to $autoload['libraries'] array in /application/config/autoload.php
I've backup of ondemand instance for sugarcrm version 8.0.0 Enterprise Edition
It works normal for CRUD records and other stuff, but when I try to upload module via Zip it gives me following error
Cross Site Request Forgery (XSRF) Attack Detected
Form authentication failure (Administration -> UpgradeWizard). Contact your administrator.
I've tried following article
Troubleshooting Cross-Site Forgery Messages
But the problem still persists. The problem only occurs for BWC modules IMO.
EDIT: Before trying this work-around, check if you have the HTTP referer header disabled in your web browser, as that might be the reason for having the described problem in the first place.
If this is a local test/dev-instance you might want to add
['csrf']['soft_fail_form'] = true,
to your $sugar_config in config.php or config_override.php. That should cause the error to be logged only instead of aborting the action.
Note: This works on Sugar 7.9. I have yet to test it on 8.0.
Source: https://community.sugarcrm.com/community/developer/blog/2017/10/11/upcoming-security-changes-to-sugar
Add this lines in your config_override.php file
$sugar_config['http_referer']['list'][] = 'http://CHANGE_TO_YOUR_LOCAL_URL/';
$sugar_config['csrf']['soft_fail_form'] = true;
I have written an application which extends CAS 3.5.3
CAS supports Kerberos protocol for authentication. So when I deploy this application on tomcat/jboss etc, I am able to login to my application via Kerberos. I have done settings on jboss. However wasn't able to find any concrete documentation for weblogic.
The documents I have found is
http://www.oracle.com/technetwork/articles/idm/weblogic-sso-kerberos-1619890.html - but this seems to be for securing the Weblogic console and now for my application.
When I try to login, getting the following error :-
Caused by: java.lang.IllegalArgumentException: No Configuration was registered that can handle the configuration named jcifs.spnego.accept
at com.bea.common.security.jdkutils.JAASConfiguration.getAppConfigurationEntry(JAASConfiguration.java:130)
at javax.security.auth.login.LoginContext.init(LoginContext.java:259)
at javax.security.auth.login.LoginContext.(LoginContext.java:425)
... 144 more
It took quiet a long time to get this right, the steps are pretty simple. If you application is using jaas and you already have Kerberos authentication code (cas) in your webapp, the following solved my issue :-
1)Keep your jaas file inside /WEB-INF/classes dir.
2) pass this as an java opt, in startweblogic.cmd
set JAVA_OPTIONS=%JAVA_OPTIONS% -Djava.security.auth.login.config=\WEB-INF\classes\jaas.conf
reboot the server and try to login.
Set the following property to JAVA_OPTIONS in your domains\your_domain\bin\startWebLogic.cmd file, or alternatively set it in weblogic console at Environment/Servers/Control/your_domain/Server Start/Arguments.
-DUseSunHttpHandler=true
How can I get a REST client (such as the one built into PHPStorm or POSTman) to work with XDebug?
In my current set-up of XDebug, using PHPStorm and the Bookmarklet provided I'm able to get it working in both Chrome and Firefox - but as soon as I try with POSTman or any other REST client, I can't figure out how to get it started.
Cheers.
You can use one of these approaches:
Configure your Xdebug (by editing php.ini) to attempt to debug every PHP script. The key option:
Xdebug v2: xdebug.remote_autostart = 1
Xdebug v3: xdebug.start_with_request = yes
Add Xdebug session start parameter to the actual URL (XDEBUG_SESSION_START={{KEY}} -- https://xdebug.org/docs/step_debug#manual-init), for example: ?XDEBUG_SESSION_START=PHPSTORM
Pass Xdebug cookie as part of the request (the one which is set by bookmarklet or browser extension, for example).
For this to work: make sure that "phone handle" icon is activated in advance in PhpStorm (Run | Start Listen for PHP Debug Connection).
P.S. If you are using Postman, Insominia or alike (another REST client) then the best / most transparent way IMO is to use Xdebug cookie. You're most likely already using separate Environments (e.g. "dev", "test", "production") so you can have such a cookie only where it is needed (depends on the tool and version used of course).
This way there is no need to edit the URL (even if you have it as a "conditional parameter" that is present for some environment and absent for another) or configure Xdebug to "debug all requests" at all.
An example of such Xdebug cookie from my Postman (edit it as needed; here it is set for the local some-domain.local.test fake domain):
XDEBUG_SESSION=value; Path=/; Domain=.some-domain.local.test; Expires=Tue, 19 Jan 2038 03:14:07 GMT;
Since the host URL should be a part of your Environment (e.g. the endpoint URL will be like {{host}}/api/v1/welcome) then such cookie will be sent to the dev domain only and not to the production one.
Just add ?XDEBUG_SESSION_START=filter_string at the end of the url, for eg:
https://new-supplier.local/api/login?XDEBUG_SESSION_START=PHPSTORM
PHPSTORM is my default filter string, you can use whatever you want. Your editor should be set up to filter connections by IDE key (filter string), and thats it. You should be able to debug the same way as from Chrome or FF.
Warning!
xdebug >= 3.0 has changed the parameters in php.ini.
After upgrading xdebug, most of the answers here will not be relevant.
Refer to:
https://xdebug.org/docs/upgrade_guide
Basically, you need to add something like this to your php.ini:
xdebug.mode=develop,gcstats,coverage,profile,debug
xdebug.start_with_request=1
xdebug.idekey=PHPSTORM
This was driving me crazy. I just updated to PHP 7.1 and xdebug that was working no longer worked. I updated the xdebug.so file (Linux) and php --version indicated that xdebug was indeed being loaded and working. But when I would use Postman the debugger never kicked on.
Here's the solution. If you are using Apache as your server then you need to enable the PHP 7.1 mods and reboot Apache: sudo service apache2 restart
xdebug.remote_timeout = 60000
Worked for me. As my Mac was very slow, and Remote debugger was timed out after 200 ms (Default value)
What finally got my Postman/PHPStorm Xdebug working was adding a PHP Remote Debug configuration in PHPStorm:
Run -> Edit Configurations -> + -> PHP Remote Debug
I just set the name to localhost and saved it - no IDE Key, etc.
you can set xdebug cookie into postman to use it from postman as well.
their are one link Cookies under the Send button click on it. and add new cookie. XDEBUG_SESSION = PHPSTORM their and save
Configure PHPStorm XDebug to trigger on RESTful API requests
Please, check this answer => https://stackoverflow.com/a/73802240/13321079