Strange issues with restricted resources & elements

I'm trying to troubleshoot a few problems some users have been having with some new websites where certain resources and chunks are login-restricted. I'm pretty certain I've got the access policies all set up correctly, but here's what's happening:

Restricted resources:
Anonymous users should see the "unauthorized" page, then can log in and view the actual resource.

Some users are reporting that after successfully logging in, they still initially see the "unauthorized" page on each restricted resource. They click the "login" link on the unauthorized page, and then are able to view the restricted resource. But this happens over and over with each restricted resource they view.

Restricted chunks:
Some pages have a paragraph embedded which originates from a restricted chunk. If the user is anonymous they should not see the chunk at all. If they are logged in, they should see the chunk.

What is happening is that occasionally the restricted chunk is showing up even for anonymous users. I observed this myself yesterday. I cleared the site cache and the anonymous user no longer was able to view the restricted chunk.

I am calling the restricted chunk uncached.

I know there are probably many variables in my setup that need to be accounted for and could be related to either or both of these problems. But are there any common "red flag" issues that I should be checking for that might be causing either of these problems?

One thing I'm wondering about in particular is caching of the resources - both the resources that are in restricted resource groups, and the resources that contain the restricted chunks. I'm not entirely clear on how caching issues relate to login/user/session issues.

Any help would be greatly appreciated.

Anything that depends on login/user/session data cannot be cached unless it accounts for all the possible results within it's own internal caching mechanism (assuming it even has one).

That said, it might be better to embed the logic of selecting the Chunks to render within a Snippet that is aware of the session data and returns the appropriate content itself. Then you can cache the individual Chunks, since they will only get included in the output based on the Snippet logic. But you would not want to use Access Permissions to restrict access to those elements on the front-end IMO.

There's a lot for me to parse/unpack in your response Jason. Let me start with the first sentence. By "cannot be cached", do you mean "must not be cached if you want it all to work as expected?" Or do you mean "the system will ignore caching directives and will always process as uncached?" I'm 99.5% sure you mean the former, but this is pretty important for me to be 100% sure about.

Regarding your second paragraph, let me see if I understand you correctly. I think you are suggesting that I:

• use an uncached snippet that is itself not restricted in any way by Access Permissions (is not in an element group that has front-end restrictions)
• Within the snippet logic, explicitly check whether the user has the authority to view the restricted element group
• If so, return the expected chunk.

Also, when you say "Then you can cache the individual Chunks, since they will only get included in the output based on the Snippet logic."... how exactly does that work. I'm a little foggy on the concept of cached/uncached when it comes to the chunk that is returned by a snippet. If I call getObject or getChunk in my return statement, is that cached or uncached by default? (I've never even considered this... I guess I always assumed if I was getting a chunk via an API call, I was getting it uncached).

Quote from: jrotering at Jun 27, 2012, 09:37 AM

By "cannot be cached", do you mean "must not be cached if you want it all to work as expected?" Or do you mean "the system will ignore caching directives and will always process as uncached?" I'm 99.5% sure you mean the former, but this is pretty important for me to be 100% sure about.

I mean the former; if you use such items cached on a Resource, the first user to access it will determine what gets cached and affect all future visitors' results to the Resource.

Quote from: jrotering at Jun 27, 2012, 09:51 AM

Regarding your second paragraph, let me see if I understand you correctly. I think you are suggesting that I:

• use an uncached snippet that is itself not restricted in any way by Access Permissions (is not in an element group that has front-end restrictions)
• Within the snippet logic, explicitly check whether the user has the authority to view the restricted element group
• If so, return the expected chunk.

Yes, except I would not use Access Permissions for the restrictions here, if that's what you are suggesting with "restricted element group". Check what "category" it's in maybe and keep it simple?

Quote from: jrotering at Jun 27, 2012, 09:51 AM

Also, when you say "Then you can cache the individual Chunks, since they will only get included in the output based on the Snippet logic."... how exactly does that work. I'm a little foggy on the concept of cached/uncached when it comes to the chunk that is returned by a snippet. If I call getObject or getChunk in my return statement, is that cached or uncached by default? (I've never even considered this... I guess I always assumed if I was getting a chunk via an API call, I was getting it uncached).

Actually, you are correct, it will not get cached since it would not be parsed until after non-cacheable processing is started. I was thinking both would get cached by tag signature, but this is not the case.

That said, if you know the user accessing the Resource in your Snippet which decides which Chunk to include, you can have that Snippet simply grab cached output from the first execution by that specific user; just create a key that is unique to the user and the Snippet and you can bypass the getChunk() after the user accesses that Resource the first time.