Bug Report

RE: RE: Issue with the current default User-Agent used by lifreray portal

2025-08-21T14:32:26Z

I just use the RSS Widget in a page and there the issue came up, no custom code - thats why i created this "bug report" as this might become a problem in the future when maybe more RSS publishers block this default user agent.

I was just curios and searched the source code for the user agent definition to provide helpful information.

Sorry for the confusion!

RE: RE: Issue with the current default User-Agent used by lifreray portal

2025-08-19T16:38:21Z

I didn't know if you were calling the HttpImpl using custom code (where you would have been able to set the user agent) or leveraging an OOTB Liferay widget. Glad you got it resolved though!

RE: Issue with the current default User-Agent used by lifreray portal

2025-08-19T16:00:40Z

Sorry, i didnt know about or find any place to set the an user-agent myself - where can i do this?

My issue was solved by the rss feed source - they unblocked the user agent for me.

RE: Issue with the current default User-Agent used by lifreray portal

2025-08-18T13:46:14Z

It only sets the default if you haven't set a user agent yourself.

You didn't provide any other context, but is this a possibility?

Issue with the current default User-Agent used by lifreray portal

2025-08-18T13:41:29Z

Hello,

i ran into an issue as the current default user agent "Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv 11.0) like Gecko" defined in com.liferay.portal.http.internal.HttpImpl is blocked for fetching RSS feed at one of my sources.

A quick research showed, that this user agent represents Internet Explorer 11 on Windows 8.1, using the user agent sting "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:141.0) Gecko/20100101 Firefox/141.0" works fine.

Maybe the default user agent should be updated to an actual user agent.

Best regards, Timo

RE: Insertion of “{}” in a structured content value

2025-03-14T18:48:30Z

Bug Report Created: https://liferay.atlassian.net/browse/LPD-51402

Insertion of “{}” in a structured content value

2025-03-14T18:41:06Z

Hello!

A possible error has been detected in which when editing a structured content, “{}” is inserted inside the Upload even though no content has been inserted in that field.

Step to reproduce:

Create a structure with 3 fields
- Content & Data -> Web Content -> Structures -> New Structure
  - Rich Text
  - Text
  - Upload
Create a content using the structure just created without inserting any value in the "Upload" field
Modify the content, without inserting any value in the "Upload" field again

Expected Results:

<?xml version="1.0"?> <root available-locales="es_ES" default-locale="es_ES" version="1.0"> <dynamic-element field-reference="descripcion" index-type="text" instance-id="G03sngQ9" name="descripcion" type="rich_text"> <dynamic-content language-id="es_ES"><![CDATA[<p>Hello World</p>]]></dynamic-content> </dynamic-element> <dynamic-element field-reference="url_externa" index-type="keyword" instance-id="JnQilYZz" name="url_externa" type="text"> <dynamic-content language-id="es_ES"><![CDATA[]]></dynamic-content> </dynamic-element> <dynamic-element field-reference="fichero_adjunto" index-type="keyword" instance-id="PxvIxa1x" name="fichero_adjunto" type="document_library"> <dynamic-content language-id="es_ES"><![CDATA[]]></dynamic-content> </dynamic-element> </root>

Actual Results:

<?xml version="1.0"?> <root available-locales="es_ES" default-locale="es_ES" version="1.0"> <dynamic-element field-reference="descripcion" index-type="text" instance-id="G03sngQ9" name="descripcion" type="rich_text"> <dynamic-content language-id="es_ES"><![CDATA[<p>Hello World</p>]]></dynamic-content> </dynamic-element> <dynamic-element field-reference="url_externa" index-type="keyword" instance-id="JnQilYZz" name="url_externa" type="text"> <dynamic-content language-id="es_ES"><![CDATA[]]></dynamic-content> </dynamic-element> <dynamic-element field-reference="fichero_adjunto" index-type="keyword" instance-id="PxvIxa1x" name="fichero_adjunto" type="document_library"> <dynamic-content language-id="es_ES"><![CDATA[{}]]></dynamic-content> </dynamic-element> </root>

Reproduced on: 7.4.3.120

RE: RenderURLs with friendly-URL mappings now contain duplicate URL-parameters

2025-02-21T20:14:55Z

Bug Report Created: https://liferay.atlassian.net/browse/LPD-49703

RE: Documentation bug report

2025-02-17T17:18:12Z

Hi Jan,

if you refer to the Docker environment parameters, the quotes are likely escaping the shell's interpretation of the contained & (and potentially other) characters. This way you can copy/paste the lines right into your shell, otherwise you'd have to escape the individual \&, which also looks weird.

Documentation bug report

2025-02-17T16:56:49Z

On https://learn.liferay.com/w/dxp/installation-and-upgrades/reference/database-templates the JDBC string contains double quotes which is incorrect.

Kind regards.

RE: RE: Required security configuration deleted on upgrade from 7.3 to 7.4

2025-02-14T16:11:16Z

For the reproduced steps outlined in the original post, I was just using an unmodified Liferay bundle, so:

com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration-accessories.config
com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration-crosssell.config
com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration-related.config
com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration-spare.config
com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration-upsell.config
com.liferay.document.library.document.conversion.internal.security.auth.verifier.image.request.module.configuration.ImageRequestAuthVerifierConfiguration-default.config
com.liferay.headless.commerce.delivery.cart.internal.jaxrs.application.HeadlessCommerceDeliveryCartApplication-default.config
com.liferay.oauth2.provider.scope.internal.configuration.BundlePrefixHandlerFactoryConfiguration-default.config
com.liferay.oauth2.provider.scope.internal.configuration.ConfigurableScopeMapperConfiguration-default.config
com.liferay.organizations.internal.configuration.OrganizationTypeConfiguration-default.config
com.liferay.portal.security.antisamy.configuration.AntiSamyClassNameConfiguration-default.config
com.liferay.portal.security.auth.verifier.internal.basic.auth.header.configuration.BasicAuthHeaderAuthVerifierConfiguration-default.config
com.liferay.portal.security.auth.verifier.internal.portal.session.configuration.PortalSessionAuthVerifierConfiguration-default.config
com.liferay.portal.security.auth.verifier.internal.tunnel.configuration.TunnelAuthVerifierConfiguration-default.config
com.liferay.portal.vulcan.internal.configuration.VulcanConfiguration-bulk.config
org.apache.aries.jax.rs.jackson.config org.apache.aries.jax.rs.whiteboard.default.config

In our actual deployments there are a few extra ones:

com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration-accessories.config
com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration-crosssell.config
com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration-related.config
com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration-spare.config
com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration-upsell.config
com.liferay.document.library.document.conversion.internal.security.auth.verifier.image.request.module.configuration.ImageRequestAuthVerifierConfiguration-default.config
com.liferay.headless.commerce.delivery.cart.internal.jaxrs.application.HeadlessCommerceDeliveryCartApplication-default.config
com.liferay.oauth2.provider.scope.internal.configuration.BundlePrefixHandlerFactoryConfiguration-default.config
com.liferay.oauth2.provider.scope.internal.configuration.ConfigurableScopeMapperConfiguration-default.config
com.liferay.organizations.internal.configuration.OrganizationTypeConfiguration-default.config
com.liferay.portal.search.elasticsearch7.configuration.ElasticsearchConfiguration.config
com.liferay.portal.security.antisamy.configuration.AntiSamyClassNameConfiguration-default.config
com.liferay.portal.security.auth.verifier.internal.basic.auth.header.configuration.BasicAuthHeaderAuthVerifierConfiguration-default.config
com.liferay.portal.security.auth.verifier.internal.portal.session.configuration.PortalSessionAuthVerifierConfiguration-default.config
com.liferay.portal.security.auth.verifier.internal.tunnel.configuration.TunnelAuthVerifierConfiguration-default.config
com.liferay.portal.security.sso.openid.connect.configuration.OpenIdConnectConfiguration.config
com.liferay.portal.security.sso.openid.connect.internal.configuration.OpenIdConnectProviderConfiguration-TNDP.config
com.liferay.portal.store.s3.configuration.S3StoreConfiguration.config
com.liferay.portal.vulcan.internal.configuration.VulcanConfiguration-bulk.config
org.apache.aries.jax.rs.jackson.config
org.apache.aries.jax.rs.whiteboard.default.config

RenderURLs with friendly-URL mappings now contain duplicate URL-parameters

2025-02-14T16:10:27Z

When switching from ga125 to ga129 custom generated RenderURLs, which have a friendly URL mapping, now contain duplicate paramters: in a friendlyURL manner as well as URL parameters.

Steps to reproduce:

1. define a renderURL in a JSP

2. Have a friendly URL mapping for the parameters defined in the renderURL

3. print the renderURL in the JSP

Expected result:

The URL in friendlyURL form, e.g. "https://{URL}/test/123"

Actual result:

The URL with duplicate parameters, as friendly URL with additionalas URL-parameters, e.g. "https://{URL}/test/123?_NAMESPACE_id=123"

RE: Required security configuration deleted on upgrade from 7.3 to 7.4

2025-02-11T13:10:36Z

Hi Chris,

Can you provide the list of file names you have in the folder {LIFERAY_HOME}/osgi/configs before the upgrade?

Thanks.

RE: Required security configuration deleted on upgrade from 7.3 to 7.4

2025-01-31T15:36:55Z

Bug Report Created: https://liferay.atlassian.net/browse/LPD-47859

Required security configuration deleted on upgrade from 7.3 to 7.4

2025-01-31T15:29:56Z

This is essentially a re-report of [LPS-159746] 403 forbidden errors in JS console when trying to use categories and tags - Jira. Despite that bug being closed as "No Longer Reproducible", I was able to trivially trigger the same underlying issue using the command line tools to upgrade a completely unmodified Liferay 7.3.6 GA7 workspace to the latest version (7.4.3 GA129).

Summary

When upgrading the database from 7.3 to the latest 7.4, a whole lot of configuration is lost, including security settings required by certain widgets to access the JSON web services. One user-visible consequence of this is that, after upgrading, it is impossible to remove events from calendars using the calendar widget, because it fails with a 403 Forbidden response from the /calendar.calendarbooking/move-calendar-booking-to-trash command.

The workaround from the original issue still works, but it's not really acceptable to have to manually enter pre-existing default configuration settings through the UI after upgrading.

Reproduction steps

For this, you'll need an external database (I used docker to run a PostgreSQL instance: docker run -d -p 5432:5432 -e POSTGRESQL_PASSWORD=password docker.io/bitnami/postgresql:14.2.0-debian-10-r14) and a Java 11 JDK (although the latest version of Liferay supports Java 17 and 21, the Blade CLI still passes arguments that were removed in Java 8 and are considered invalid in recent versions of Java).

Use the Blade CLI to create a Liferay 7.3 workspace: blade init -v portal-7.3-ga7 && blade server init.
Edit bundles/portal-ext.properties to point at the external database.
Run the server to create and populate the database schema: blade server run
Use the database upgrade tool (Using the Database Upgrade Tool - Liferay Learn) to upgrade the database schema to 7.4.3 GA 129.
Use the Blade CLI to create a Liferay 7.4 workspace: blade init -v portal-7.4-ga129 && blade server init.
Edit bundles/portal-ext.properties to point at the external database.
Run the server: blade server run.
Logging in to Liferay on localhost:8080 as test@liferay.com:
1. Add the calendar widget to the home page.
2. Add an event to the user calendar.
3. Try to delete the event - it fails with a 403 Forbidden response.
4. In the Control Panel, go to System Settings > API Authentication > Portal Sessions and note that there's nothing there.
Compare this to a fresh install of Liferay 7.4:
1. Stop the server using ctrl-c, clear the database (if you're using docker, just stop the container and start a new one) and restart the server.
2. Redo step 8 and note that the Portal Sessions settings now have a URLs Includes entry with value /api/json*,/api/jsonws*,/c/portal/json_service*.

To me, this seems to be an obvious bug in the upgrade process. An upgraded Liferay installation shouldn't be lacking required configuration that a fresh installation has. This issue is currently blocking us upgrading our clients to the latest version of Liferay.

For completeness, below are the contents of the configuration_ table at various stages of the process.

In Liferay 7.3.6 GA7:

postgres=# select configurationid from configuration_;
                                                                                        configurationid
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 com.liferay.oauth2.provider.scope.internal.configuration.BundlePrefixHandlerFactoryConfiguration.34bb94a7-06cf-4d22-9d34-ec6ae5a515aa
 com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration.63452976-e696-4d40-9191-ca61a634d7ad
 org.apache.aries.jax.rs.jackson
 com.liferay.document.library.document.conversion.internal.security.auth.verifier.image.request.module.configuration.ImageRequestAuthVerifierConfiguration.cf0ee241-314e-4ae9-8c7f-0581f4dfb4ec
 com.liferay.oauth2.provider.scope.internal.configuration.ConfigurableScopeMapperConfiguration.c938ffbd-93ee-4211-b6d6-372376ab93af
 com.liferay.portal.security.auth.verifier.internal.portal.session.configuration.PortalSessionAuthVerifierConfiguration.ce83585e-c9f2-462e-af1d-c2bc1302950d
 com.liferay.portal.security.auth.verifier.internal.basic.auth.header.configuration.BasicAuthHeaderAuthVerifierConfiguration.06f16fe0-e535-4a77-9fe3-7a8047c8acf4
 com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration.9c9cd697-633b-472b-a639-480557e90180
 com.liferay.portal.security.auth.verifier.internal.tunnel.configuration.TunnelAuthVerifierConfiguration.7fcb6973-d9c7-482e-9ca4-b133ab825da4
 com.liferay.headless.commerce.delivery.cart.internal.jaxrs.application.HeadlessCommerceDeliveryCartApplication.e1a66db6-e501-4a9f-8c15-f929d9fc33ea
 org.apache.aries.jax.rs.whiteboard.default
 com.liferay.portal.security.antisamy.configuration.AntiSamyClassNameConfiguration.99337f19-9dc4-414a-a122-b61670c3ded9
 com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration.a2dcb630-a9a7-49a8-945e-51cb84cdfd9b
 com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration.e661476c-dd66-45a3-9c9b-ab31a1039ce6
 com.liferay.portal.vulcan.internal.configuration.VulcanConfiguration.9e0b57f1-c287-4eee-8758-8e3b754d8d04
 com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration.6b89bb50-d27d-4749-8d64-67a19c1b13ed
 com.liferay.organizations.internal.configuration.OrganizationTypeConfiguration.bb5a4bf4-5fb1-4eac-9ffe-5997997ad67d
(17 rows)

After upgrading the database to Liferay 7.4.3 GA 129:

postgres=# select configurationid from configuration_;
                                        configurationid
------------------------------------------------------------------------------------------------
 com.liferay.captcha.configuration.CaptchaConfiguration
 com.liferay.oauth2.provider.rest.internal.configuration.OAuth2AuthorizationServerConfiguration
 com.liferay.layout.seo.web.internal.configuration.LayoutSEODynamicRenderingConfiguration
 com.liferay.journal.web.internal.configuration.JournalWebConfiguration
 com.liferay.batch.engine.configuration.BatchEngineTaskConfiguration
(5 rows)

Most of the configuration has been deleted (which may or may not be intentional). As an aside, I notice that the report generated by the upgrade tool is a lie, claiming that there were initially only 2 rows, when in fact there were 17.

After running Liferay 7.4.3 GA 129 against the upgraded database:

postgres=# select configurationid from configuration_;
                                                       configurationid
-----------------------------------------------------------------------------------------------------------------------------
 com.liferay.captcha.configuration.CaptchaConfiguration
 com.liferay.oauth2.provider.rest.internal.configuration.OAuth2AuthorizationServerConfiguration
 com.liferay.layout.seo.web.internal.configuration.LayoutSEODynamicRenderingConfiguration
 com.liferay.journal.web.internal.configuration.JournalWebConfiguration
 com.liferay.batch.engine.configuration.BatchEngineTaskConfiguration
 com.liferay.commerce.payment.configuration.CommercePaymentEntryRefundTypeConfiguration~0a28ef1a-2ec3-4564-8a1a-bd9a71cb7446
 com.liferay.commerce.payment.configuration.CommercePaymentEntryRefundTypeConfiguration~a622c2b8-7b59-4be9-a618-fbfd3d72ea1c
 com.liferay.commerce.payment.configuration.CommercePaymentEntryRefundTypeConfiguration~b7bc2dd8-b7a2-4ad6-8dc6-584fad12e4fa
 com.liferay.portal.vulcan.internal.configuration.VulcanCompanyConfiguration~4cef77cb-e060-4756-9c1e-13bcda3c3d8a
 com.liferay.portal.vulcan.internal.configuration.VulcanCompanyConfiguration~ca03b7de-abc6-4c21-995d-2774a6d19960
 com.liferay.portal.vulcan.internal.configuration.VulcanCompanyConfiguration~8d32944d-cb01-4b2a-92ca-43cf8709a7ea
 com.liferay.portal.vulcan.internal.configuration.VulcanCompanyConfiguration~814b1717-c2eb-4946-a67d-2e0055bbb83e
(12 rows)

There are a few new entries, but not as many as before the upgrade and the relevent setting for this issue (com.liferay.portal.security.auth.verifier.internal.portal.session.configuration.PortalSessionAuthVerifierConfiguration) is still missing.

Compare a fresh Liferay 7.4.3 GA 129 install:

postgres=# select configurationid from configuration_;
                                                                          configurationid
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
 com.liferay.portal.remote.cors.configuration.PortalCORSConfiguration~default
 org.apache.aries.jax.rs.jackson
 com.liferay.adaptive.media.image.internal.configuration.AMImageMagickConfiguration
 com.liferay.organizations.internal.configuration.OrganizationTypeConfiguration~default
 com.liferay.headless.commerce.delivery.cart.internal.jaxrs.application.HeadlessCommerceDeliveryCartApplication~default
 com.liferay.document.library.document.conversion.internal.security.auth.verifier.image.request.module.configuration.ImageRequestAuthVerifierConfiguration~default
 com.liferay.oauth2.provider.rest.internal.configuration.OAuth2AuthorizationServerConfiguration
 org.apache.aries.jax.rs.whiteboard.default
 com.liferay.portal.security.antisamy.configuration.AntiSamyClassNameConfiguration~blogs
 com.liferay.portal.security.antisamy.configuration.AntiSamyClassNameConfiguration~knowledgebase
 com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration~accessories
 com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration~cross-sell
 com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration~related
 com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration~spare
 com.liferay.commerce.product.configuration.CPDefinitionLinkTypeConfiguration~up-sell
 com.liferay.oauth2.provider.scope.internal.configuration.BundlePrefixHandlerFactoryConfiguration~default
 com.liferay.oauth2.provider.scope.internal.configuration.ConfigurableScopeMapperConfiguration~default
 com.liferay.portal.vulcan.internal.configuration.VulcanConfiguration~bulk
 com.liferay.portal.security.auth.verifier.internal.basic.auth.header.configuration.BasicAuthHeaderAuthVerifierConfiguration~default
 com.liferay.portal.security.auth.verifier.internal.portal.session.configuration.PortalSessionAuthVerifierConfiguration~default
 com.liferay.portal.security.auth.verifier.internal.tunnel.configuration.TunnelAuthVerifierConfiguration~default
 com.liferay.commerce.payment.configuration.CommercePaymentEntryRefundTypeConfiguration~f94ba4cb-5c56-4f2b-b562-a9df50af0452
 com.liferay.commerce.payment.configuration.CommercePaymentEntryRefundTypeConfiguration~857ecdd6-d17c-4cc9-835b-aefa3526c28d
 com.liferay.commerce.payment.configuration.CommercePaymentEntryRefundTypeConfiguration~a3305cfc-ac57-4dce-b7e2-363a8b904a57
 com.liferay.portal.vulcan.internal.configuration.VulcanCompanyConfiguration~ba73bc95-4098-4a74-adf8-020cbc617383
 com.liferay.portal.vulcan.internal.configuration.VulcanCompanyConfiguration~c605fc0d-afd1-473b-8cc0-9c79a6a0ce36
 com.liferay.portal.vulcan.internal.configuration.VulcanCompanyConfiguration~555332f3-b725-4e64-9d16-b58e637f6bff
 com.liferay.portal.vulcan.internal.configuration.VulcanCompanyConfiguration~be85747e-23db-4df2-aa7a-ba079a333a72
(28 rows)

RE: RE: OpenID Connect session is not synced with IdP

2025-01-24T10:42:57Z

Np Jan, the "Ofline" may be a bit misleading, indeed.

RE: RE: OpenID Connect session is not synced with IdP

2025-01-24T10:23:09Z

I was fooled by the "Offline" prefix of that scheduler assuming it was for something else. And partly also by the GitHub search highlighter showing just the first few occurrences, but I was too impatient and did not seek it further in the remaining code. Finally, I assumed incorrectly the scheduler triggers the refresh at that configured rate, but it does so only if the original token is near expiration. The expiration of the token was greater so I was puzzled why the session was not closed. Now I understand.

RE: OpenID Connect session is not synced with IdP

2025-01-24T10:12:26Z

Hi Jan,

The scheduler is registered here and the communication towards the OIDC Provider is triggered here and the communication goes here. The process updates the access token expiration date. Were you looking for this?

Nevertheless, your last sentence suggests that something is not working on your side. Does the info above help you to progress in investigating the problem?

Regards,
Zsigmond

RE: Configuring Unicast over TCP: typo in cluster link properties sample

2025-01-22T16:28:33Z

Bug Report Created: https://liferay.atlassian.net/browse/LPD-46979

OpenID Connect session is not synced with IdP

2025-01-23T06:58:26Z

When OIDC is enabled, it is possible to configure the refresh interval: System Settings | SSO | OpenID Connect | Token Refresh Scheduled Interval

It gives the false assumption the session is regularly synced with IdP, however, looking into the LR code I can't see any scheduler communicating with IdP (refreshing the token), let alone utilize this configured value.

Now, if the IdP session is closed outside of LR, LR can't detect this and logout the user automatically.