The Security Basics trailhead asks whether client IP address can affect the data you can see, and expects the answer "Yes". Scanning the security documentation it seems that IP address provides All or Nothing control via login restrictions, but can it vary what you see once you're in? I'd still answer "No" to that question as it doesn't appear that my permissions change depending on my IP address. Only whether or not I can access the system at all.

We're trying to optimise code - new CPU governor and all that - and have found something strange with set.retainAll().

Given sets A and B, we'd expect A.retainAll(B) to be pretty fast. According to Wikipedia's article on HashSet performence we'd expect O(n). When the set becomes very large, we see rapidly diminishing performance.

The strange thing is if we implement it ourselves.

/* pseudocode */
For (itemA : setA){
    if(!setB.contains(itemA)){
        setA.remove(itemA);
    }
}

Given that this involves two hash lookups to do a remove, rather than being able to take advantage of something like Java's Iterator.remove() method, we'd expect it to be slower.

The only risk is that we're modifyin a set while iterating over it. Will this break things?

We could also perform the operation by copying into a new Set, but this takes a little more heap (only a little, as it's copy by reference of course).

/* pseudocode */
Set outputSet = new Set();
For (itemA : setA){
    if(setB.contains(itemA)){
        outputSet.add(itemA);
    }
}

We're trying to optimise code - new CPU governor and all that - and have found something strange with set.retainAll().

Given sets A and B, we'd expect A.retainAll(B) to be pretty fast. According to Wikipedia's article on HashSet performence we'd expect O(n). When the set becomes very large, we see rapidly diminishing performance.

The strange thing is if we implement it ourselves.

/* pseudocode */
For (itemA : setA){
    if(!setB.contains(itemA)){
        setA.remove(itemA);
    }
}

Given that this involves two hash lookups to do a remove, rather than being able to take advantage of something like Java's Iterator.remove() method, we'd expect it to be slower.

The only risk is that we're modifyin a set while iterating over it. Will this break things?

We could also perform the operation by copying into a new Set, but this takes a little more heap (only a little, as it's copy by reference of course).

/* pseudocode */
Set outputSet = new Set();
For (itemA : setA){
    if(setB.contains(itemA)){
        outputSet.add(itemA);
    }
}

Last week, it was brought to my attention that security reviews and audits are now asking ISVs to check for Field Level Security (FLS) and Object CRUD permissions prior to any DML outside of standard controllers.  

This is a fairly radical change that impacts a lot of managed package applications across the board. I and others have several concerns about this change in the security review process:

1. Why the sudden change in security review policy?  
   • None of the ISVs I have talked to were informed of the change prior to being either audited or submitting any apps for security review.  The only official documentation I can find on the change is a blurb in the Security Scanner help page here: http://security.force.com/security/tools/forcecom/scannerhelp.  
   • As ISVs, it would be greatly appreciated to have an official Security Review Guide, that is updated well in advance to when policy changes like this take place.  Some ISVs have several packages, others lots of customizations, and we all need time to prepare for the security review.
2. Has the security scanner been updated to enforce this rule yet?
   1. I have not run an app through the Security Review process recently, so I am curious if this rule has been implemented already in the security scanner. (http://security.force.com/security/tools/forcecom/scanner)
3. Why force FLS and CRUD checks on every DML transaction?
   • I am a fan of using standard controllers when necessary, but several apps, including one my company develops rely heavily on Custom Controllers.  In most cases where FLS comes into play, typically it's a simple fix of a profile permission or permission set that resolves the issue.  Instead, now, we have to implement FLS and CRUD checking prior to each DML transaction.  This adds complexity on top of existing DML calls.  
   • If need be, can the FLS and CRUD checking be done on a one-time run in an install script?
   • Does Salesforce have any plans of either adding FLS checking for custom controllers or adding methods to Apex for checking credentials similar to the Force.com EASPI library? (https://code.google.com/p/force-dot-com-esapi/)

Thanks, I look forward to hearing any feedback on this issue.

Is it implementation of stack concept in apex class or something else??

Hi,

 

If I create a custom component, is there any way to update a value on the parent controller? Let's say as a parameter passed into the custom component, I gave a value like {!value}. Can the controller behind the custom component modify that variable that's on the main page's custom controller? In java you might do this with a shared bean or session variable. What about in apex?

 

I have several VF tabs on my page. Each tab is a different business function. I end up re-using code on multiple VF pages so it would be great to make each tab a component so I can re-use thm elsewhere.  Right now it's monolithic. But a link on one tab may cause the VF page to jump you to another tab and use a commandlink parameter.

 

So if we were to break this up into custom components, we would need to somehow pass data between them. Is that possible somehow? It looks like variables only flow one way or maybe we just don't know how to do it?

 

Any thoughts?

 

Thank you,

DSL