Cookies error

[Former Community Member]

Hi,

I keep having this problem when signing in

"You have reached this page because cookies might not be enabled on your browser. Please enable the cookies and then re access the LiveCycle application."

I'm pretty sure the cookies were enabled on the browser (Chrome). I tested with firefox and IE too and they were having the same problem.

I Tried to clear cookies too but it does not help 

[smacdonald2008]

What product you are using? This looks like you are in the wrong community. 

[Former Community Member]

smacdonald2008 wrote...

What product you are using? This looks like you are in the wrong community. 

Hi,

I using AEM Forms JEE on JBOSS

[Former Community Member]

Anyone has any idea on why this is happening?

Thanks

[tw99384403 · Accepted solution]

I experienced same issue.  I was using latest version of Firefox when it occurred (51), which is currently supported according to link pasted below.  I uninstalled and installed an older version (45.2).  

https://helpx.adobe.com/aem-forms/6-2/AEM-forms-JEE-supported-platforms.html#Browsers

[DarrenBiz]

We see this error a lot, especially when we implement LDAP and SAML on the JEE server. It is a catch-all error that it part of the UM War (UserManager) and usually has very little to do with Cookies. You can often see it when you try to log in with one session (e.g. AdminUI) and use another browser tab to open another session (e.g. LDAP/SAML). The best thing we find to fix it is close all browser windows and try to login again.

The code behind this page (enable_cookies.jsp) says this:

/**
SSOFilter would forward to this jsp if it is not able to detect any redirect related information. It would infer
that cookie is not enabled and hence would show an appropriate message
*/

Which isnt very helpful.

[Jared_Langdon]

I'm getting this same error, but I suspect it's for different reasons.  I'm pretty sure there's nothing wrong with my browser version or configuration because I was logging into Workspace earlier today.  I then installed AEM Forms Workbench and logged into that.  Ever since, I'm getting the cookies message when I try to access Workspace.  I have cleared my browser cache, restarted my browser, and even restarted my computer to no avail.  I bounced JBoss too.  Still getting the problem.  I can log into Workbench and I can log into adminui no problem.

When I pass my correct credentials in the login form I see this in the log:

11:50:57,401 INFO [org.apache.xml.security.signature.Reference] (http-/0.0.0.0:8080-1) Verification successful for URI "#d20bdb5b80881a21d34b419db9bfbcd1"

When I pass a bogus password, I see this in the log:

11:50:57,526 WARN [com.adobe.idp.um.businesslogic.authentication.AuthenticationManagerBean] (Thread-428) Authentication failed for user [langdonj] (Scheme - Username/Password) Reason: Username or password is incorrect . Refer to debug level logs for category com.adobe.idp.um.businesslogic.authentication for further details

So, it's getting my credentials and validating them.

I guess the next troubleshooting step would be to enable debug level logging.  Can someone point me to the instructions for that.  Do I have to run configuration manager?

Thanks.

[smacdonald2008]

If you install on a fresh server - do you see this issue? Looks like there is an issue with your environment.

[Jared_Langdon]

Thanks Scott.  It's a fresh install, but it was working as of earlier today.  Then I installed Workbench on my workstation and logged into that.  Afterwards I could not log in to Workspace.  I'm guessing that these things are related because of what DarrenBiz said about "You can often see it when you try to log in with one session (e.g. AdminUI) and use another browser tab to open another session".  His remedy didn't work for me though. 

I'll prepare a support ticket, but it would be helpful to have a server log at the DEBUG or TRACE level to send to them.  Can you point me to instructions on how to change the logging level?  Thanks so much.

[Jared_Langdon]

I'll answer my own question about the logging.  The settings are in lc_turnkey.xml.  I modified the setting for periodic-rotating-file-handler and <logger category="com.adobe">, changing "INFO" to "DEBUG".  I'm not sure if it was necessary to change both or if one would have been sufficient.  I restarted JBoss and my logs became much more detailed.

Unfortunately, the detailed logs didn't help me much in figuring out what's causing the "cookies" screen to appear upon logging on to Workspace.  Below are a few lines that may be relevant.  I've put in bold the bits that made me think these may be relevant.

09:29:12,246 DEBUG [com.adobe.idp.um.businesslogic.authentication.AuthenticationManagerBean] (Thread-386) UserM:: [Thread Hashcode: 1475448974] Trying to authenticate against AuthProvider com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl

09:29:12,246 DEBUG [com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl] (Thread-386) UserM:: [Thread Hashcode: 1475448974] Authenticating with LDAP Auth Provider

09:29:12,246 DEBUG [com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl] (Thread-386) UserM:: [Thread Hashcode: 1475448974] Domains fetched for LDAP Authentication

09:29:12,246 DEBUG [com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl] (Thread-386) UserM:: [Thread Hashcode: 1475448974] Authenticating against LMNOP domain

09:29:12,309 DEBUG [com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl] (Thread-386) UserM:: [Thread Hashcode: 1475448974] Got DN for user langdonj

. . .

09:29:12,434 DEBUG [com.adobe.idp.um.businesslogic.authentication.AuthenticationManagerBean] (Thread-386) Authentication successful for com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl and the user is identified as langdonj . . .

. . .

begin sql[http-/0.0.0.0:8080-1] - 
SELECT  COUNT(*)  FROM tb_cache_config T0  WHERE T0.qname = 'Replicated:UM_COOKIE_SESSION_CACHE'

09:29:12,449 DEBUG [com.adobe.pof.adapter.LoggablePreparedStatement] (http-/0.0.0.0:8080-1) 2948:. end sql[http-/0.0.0.0:8080-1, 0

. . .

09:29:12,449 DEBUG [com.adobe.idp.um.server.cache.UMCacheManager] (http-/0.0.0.0:8080-1) Using cacheType [Replicated] for Cache [UM_COOKIE_SESSION_CACHE]

09:29:12,449 DEBUG [com.adobe.idp.um.auth.filter.SSOFilter] (http-/0.0.0.0:8080-1) Successfully authenticated so redirecting to source_url?login_result=0 also added the auth cookie with Id 5AF65F09-FE4F-B55B-15A4-2A2BFE2495DE

[Jared_Langdon]

Okay I have the fix for this, which came from Adobe Support.  This resolved the problem for me:

1) Stop JBoss

2) Delete all folders except for "install" under the crx-repository directory

3) Start JBoss

[Jared_Langdon]

I have a couple of things to add to this.

1) Rebuilding the entire repository as I've described is a pretty heavy-handed workaround.  That said, I don't have a better idea and neither does Adobe Support at this time.

2) Coming from LC ES3, I'm used to restarting JBoss and watching for the "started in N seconds" line in the log, at which point I know that everything's up and running.  That's not the case here.  If you rebuild the repository it's advisable to wait quite a bit longer (like 1 hour or more) before you access workspace.

3) I believe the problem occurs after logging into CRXDE Lite and AEM Forms Workspace at the same time with the same user account and the same browser.  This causes AEM to get into some conflicty state where you can no longer log into AEM Forms Workspace.  I have adopted a habit of using separate user accounts and separate browsers for CRXDE Lite and Workspace.  Since I started that practice, I have not had the dreaded Cookies problem.

[Mayank_Gandhi]

Hi Jared,

Adding to your 2nd point.

Since you have been using J2EE side from long .Instead of just waiting for an hour a good to way to confirm the start /stop operation is to tail the CRX error logs( [AEM-Installation-Directory]/crx-quickstart/logs) and see it the logs have stabilized.So, apart from App server logs, CRX error logs and OSGI bundle state may give you an information about the successful start of an instance.The same would also help in scenarios when you have to patch the environment with any CFP or SP .

[DarrenBiz]

Hi Mayank. If we wanted to automatically scan for AEM Forms being ready in the OSGi environment, what should we specifically look for from a logging perspective?

I saw this line recently and wondered if this is what we should scan for:

1. 09.04.2018 14:47:08.833 *INFO* [FelixDispatchQueue] com.adobe.fd.core.startup.AEMFormsStartupListener AEMFormsStartupListener -- startup has finished

[Mayank_Gandhi]

Hi Darren,

Although checking for 'AEMFormsStartupListener -- startup has finished' is a good option but you may find that in the number of cases it might not appear in the logs.The best way again would be to log in to system/console and check for the bundle's state.

[RayHundley]

We are starting to experience this problem as well.   We are running AEM forms 6.2

So far the only difference seems to be the the users getting the error are running Chrome on a Windows 10 machine.

Using Chrome on a Windows 7 machine seems to work ok.

[david_mcmahon]

I had this problem also and found another possible reason.

I was using the long URL to access Workspace:

http://<aem_forms_server>/lc/libs/livecycle/core/content/login.html?ap=1

I get the error about the cookies in every browser (Chrome, FF, IE and Edge), both on the server itself, and through remote access.

When I switched to the short URL, it works:

http://<aem_forms_server>/lc/ws

So this error seems to have multiple causes, which reflects the previous comment that it appears to be a catch all, when an unexpected error occurs.