authenticate anonymous user on publish instance | Community
Skip to main content
K
Ka_On_Leung
Level 2
October 16, 2015
Solved

authenticate anonymous user on publish instance

  • October 16, 2015
  • 6 replies
  • 5522 views

By default anonymous user is allowed to view geometrixx page without any authentication on publish instance.  Other than create a new CQ user with read permission on /content/geometrixx, is it possible to add authentication when anonymous user try to view geometrixx page? 

The anonymous user authentication can be similar to the authentication when user trying to enter http://localhost:4053/system/console.  A window will prompt and request for a correct username and password.

Thanks

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by PaulMcMahon

The standard solution for this in CQ is to use Closed User Groups -  http://dev.day.com/docs/en/cq/current/howto/create_apply_cug.html. 

Based on your exact use case this may be the right approach. If you are using dispatch you will have make some changes to dispatcher to make that work - see http://dev.day.com/docs/en/cq/current/deploying/dispatcher/permissions_cache.html. There some pros and cons to how you go about doing this (and some issues with the instructions). You can check out this presentation that describes some of those issues - http://www.slideshare.net/evolve_conference/evolve13-enhance-26102078.

6 replies

P
PaulMcMahonAccepted solution
Level 8
October 16, 2015

The standard solution for this in CQ is to use Closed User Groups -  http://dev.day.com/docs/en/cq/current/howto/create_apply_cug.html. 

Based on your exact use case this may be the right approach. If you are using dispatch you will have make some changes to dispatcher to make that work - see http://dev.day.com/docs/en/cq/current/deploying/dispatcher/permissions_cache.html. There some pros and cons to how you go about doing this (and some issues with the instructions). You can check out this presentation that describes some of those issues - http://www.slideshare.net/evolve_conference/evolve13-enhance-26102078.

K
Ka_On_LeungAuthor
Level 2
October 16, 2015

Orotas thanks for your reply

CUG doesn't seems to work in my use case.

 

Currently we have set up 3 cq instances: 1 author and 1 publish instance and we have also setup a staging instance for page preview use ( the staging instance is configured as a publish instance but running different port number) .  When an author submit an approval workflow, the content to replicate to staging server first, a reviewer will preview the page in staging instance and the approve the content if it is ok.  Then the content will be scheduled to replicate to the publish instance.  The staging server is only for internal use hence we want to authenication before previewing the content.

If CUG is used, it will cause the page also need authentication when the page is published in publish instance.  Therefore I want to know if there is any way so that only in staging instance, there will be some authentication similar to the authentication when user trying to enter http://localhost:4053/system/console.  A window will prompt and request for a correct username and password.

joerghoh
Adobe Employee
joerghohAdobe Employee
Adobe Employee
October 16, 2015

In that case you should do the authentication on the webserver which should be placed in front of you QA publish instance.

Nevertheless, the proper QA workflow is supposed to like this (according to the product philosophy):

  1. The editor thinks, that the page is OK, and starts the approval workflow
  2. The QA people will receive an email, click on the link provided in that email.
  3. This links takes the QA person to the authoring environment, where she authenticates herself first and then redirects her to the page.
  4. When the page is ok, the QA person continues the workflow and then the page gets automatically published.

In that case the full QA/preview functinoality should work on authoring, which shouldn't be a problem most of the time.

Jörg

K
Ka_On_LeungAuthor
Level 2
October 16, 2015

Thanks for your reply Jorg Hoh

It is because that while a QA people is previewing a page, there maybe other authors edit the page at the same time.  The QA people may preview the wrong content if he preview the page in author instance.  Hence we have setup a staging stance (QA publish instance) for preview use only.

Unfortunately our QA publish instance is not connected to a web server.  Therefore authentication cannot be done on web server.  Can CQ publish instance facilitate the same authentication mechanism?

Thanks

joerghoh
Adobe Employee
joerghohAdobe Employee
Adobe Employee
October 16, 2015

Hi,

hm, how do you activate a previewed and approved page then, when a different user has already made some more changes? When you simply hit "activate" now, you activate these not yet approved changes as well. So I would reconsider the whole approval workflow.

And by the way: Have you already considered to use "Launches" [0]?

Jörg

[0] http://dev.day.com/docs/en/cq/current/wcm/launches.html

A
Anonymous
October 16, 2015

I guess we can enable authentication in Publish mode also.

By default in publish mode authentication is disabled.

Go to OSGI configurations and search for sling authentication service here you can enable authentication.

Terms & ConditionsAccessibility statement

Loading footer...