Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
 
					
				
		
 Jason_Michaelid
		
			Jason_MichaelidHi all,
Has anybody tried using Direct Discovery on Section Access? Is it possible? I don't need to refresh my app's data more than a few times a day, but the security must be up-to-the-minute (preferably real-time from source, hence DD).
Thanks
Jason
 
					
				
		
 marcus_sommer
		
			marcus_sommer
		
		
		
		
		
		
		
		
	
			
		
		
			
					
		I think it won't be possible in this way because section access will only applied by opening an application and not by reloading it. Should an access-control happens on a reload-process the access-control would need to be transferred to user-depending where-conditions - possible but expensive and probably with some side-effects.
If a regular reloading or closing/reloading/opening is rather not suitable I could imagine that instead or additionally to a section access an access-control could be applied over field- or variable-flags - which are set/changed per DD - and which are serving as conditions for sheets/objects and dimensions/expressions plus as true/false-flags within the expressions.
Of course such an implementation will be quite expensive, too and providing only a full access-contol if the user couldn't create/adjust objects/variables because otherwise a (more experienced) user could bypass this logic.
- Marcus
 
					
				
		
 jonathandienst
		
			jonathandienst
		
		
		
		
		
		
		
		
	
			
		
		
			
					
		Perhaps a binary load followed by a re-application of the section access? I don't think DD data is available at the time of load, so I doubt you can apply section access using DD.
 
					
				
		
 marcus_sommer
		
			marcus_sommer
		
		
		
		
		
		
		
		
	
			
		
		
			
					
		I think it won't be possible in this way because section access will only applied by opening an application and not by reloading it. Should an access-control happens on a reload-process the access-control would need to be transferred to user-depending where-conditions - possible but expensive and probably with some side-effects.
If a regular reloading or closing/reloading/opening is rather not suitable I could imagine that instead or additionally to a section access an access-control could be applied over field- or variable-flags - which are set/changed per DD - and which are serving as conditions for sheets/objects and dimensions/expressions plus as true/false-flags within the expressions.
Of course such an implementation will be quite expensive, too and providing only a full access-contol if the user couldn't create/adjust objects/variables because otherwise a (more experienced) user could bypass this logic.
- Marcus
 
					
				
		
 Jason_Michaelid
		
			Jason_Michaelidthanks Jonathan. I’m not yet sure if the size of the final app so don’t know if BL “on demand” or every minute is feasible. At reload I could just query the data source in the script execution to refresh the SA but again I don’t know how often I’ll be able to reload due to app size. Thanks for your help mate - appreciated.
 
					
				
		
 Jason_Michaelid
		
			Jason_MichaelidThanks Marcus. I think OSUser() in Set Analysis will be the way to go. I was hoping to avoid for the reasons you’ve given, however given this will be a mashup in a DMZ I think it’ll be ok. I just need to check it can’t be bypassed!
Thanks For the suggestions sir.
Jason
 SteveNewman
		
			SteveNewman
		
		
		
		
		
		
		
		
	
			
		
		
			
					
		Another common approach that is more dynamic is to move to a “group” based security model that allows you to dynamically change groups when the user logs in. This allows you to have, up to minute security applied to Qlik applications when the user logs into Qlik.
For example, lets say that you secure your data by zip code (postal code). You could create a Section Access table, dynamically for every zip code (postal code) in your data. When a user logs in, you could assign groups to the user (either from your security source, LDAP, etc... or via a UDC pulling from a database). For example, you could add 100 zip codes (postal codes) to user1 and 269 to user2.
Since your zip codes in your data don’t change, except during reloads, you don’t have to worry about extra reloads. However, since your users access rules can changes 1,000’s of times a day (theoretically) you can change those more dynamically.
Also, don’t forget you can create compound groups using a typically REDUCTION technique discussed in other articles.
I have implemented similarly in environments with 5,000+ groups without problems.
Hope that helps.
 
					
				
		
 Jason_Michaelid
		
			Jason_MichaelidThats’s a great idea Steve - thank you!
