About AndrewF

AndrewF · ‎06-07-2021

@jamiemccardle wrote: If we allow grant see categories for the Product Family then Deny for each subcategory The proposal shown in the screenshots is that the topmost category should be denied to all users by default the inner categories should be selectively opened to specific roles. The screenshots do a good job of showing what I mean and how the settings manifest, but here is a "massaged" internal data dump, in case it is clearer: Nodes Node ID Path Node Type 9 /1/2/ pub Category 10 /1/2/ priv Category 11 /1/2/9/ pub1 Category 12 /1/2/9/ pub2 Category 13 /1/2/9/ pub3 Category 14 /1/2/9/11/ pub1a Board 15 /1/2/9/11/ pub1b Board 16 /1/2/9/12/ pub2a Board 17 /1/2/9/12/ pub2b Board 18 /1/2/9/13/ pub3a Board 19 /1/2/9/13/ pub3b Board 20 /1/2/10/ priv1 Category 21 /1/2/10/ priv2 Category 22 /1/2/10/ priv3 Category 23 /1/2/10/20/ priv1a Board 24 /1/2/10/21/ priv2a Board 25 /1/2/10/22/ priv3a Board Default permissions for nodes Node ID Path Node Permission Permissions 10 /1/2/ priv Deny read_board, read_category, read_message Role permissions for nodes Node ID Path Node Role Name Permission Permissions 20 /1/2/10/ priv1 Private #1 Grant read_board, read_category, read_message 21 /1/2/10/ priv2 Private #2 Grant read_board, read_category, read_message 22 /1/2/10/ priv3 Private #3 Grant read_board, read_category, read_message I do not recommend using JavaScript to hide anything that is secret. Such hidden things will still be present in the page markup (not secret), and when the page is loaded, some users will see the content render and then flicker away, which can be jarring. If you do wish to use JavaScript in your FreeMarker customizations, especially using jQuery as mentioned by @akshays, I recommend that you use the liaAddScript directive to ensure that the script runs properly and can be supported over time as the platform receives UI updates.

AndrewF · ‎02-01-2021

Hi Mike, if you need to do multiple redirects or stages of the user flow, I recommend totally owning those steps outside the community. So you would implement a new interim location for the community to send a user to, and that request's query string will bear the community's "return" URL. From there, if you need the user to go through more steps, you'll want to pass that stateful data along in your own secure way. It's neater for your application to manage those handoffs because you can validate and secure the redirect URLs according to your own policies, and you can also update your overall flow in any future way without worrying about updating the community's configuration or sequencing the change just right across platforms. As a rough example: Community sends user to //YOURSITE/login?redirect_to=https://COMMUNITY/welcomeback/ You validate the redirect URL https://COMMUNITY/welcomeback/ and set it as a (trusted) property of the user's session You perform a myriad of auth-related tasks, maybe bouncing through a couple URLs, and eventually, the user is logged in You check for the community redirect URL, and if it is there, you set the necessary cookies and forward the user along to their final destination Using the session is just one way to carry that state across the flow. You could also encrypt the final destination, or even pass it along via cleartext query parameters. Just make sure you've properly validated the URL before you use it.

MattV · ‎01-18-2019

Services generally doesn't add tracking code unless it's at the customers direction. And on many projects I work on, the customers themselves will add the tracking code, because they have been given the specific instructions to implement from the tracking provider and their SEO team, and all we do is point to where the code should be added in studio. I'm glad you were able to solve this.

sherrie · ‎10-25-2017

Thank you so much @AndrewF, that resolved the issue!

AndrewF · ‎03-29-2017

Hi Gina, Lithium typically doesn't expose the implementation details of our services except at defined integration points (i.e., places you can talk to directly). Even if we did, things are subject to naturally change over time in order to meet new demands of the platform. Fortunately for your developers, our datastore details shouldn't have to play a role in their considerations since everything would be done via public APIs.

Online Status	Offline
Date Last Visited	3 weeks ago

Re: Permission Question

Re: How to include referer in login URL

Re: Removing ClickTale

Re: API permissions issues

Re: What database does Lithium run on?