You need to sign in to do that
Don't have an account?
Signagelive Development
Additional Protection Against Forced Login Attempts - Will it affect us?
We received an email from Salesforce this morning regarding additional protection against forced logins that is being introduced in the next update.
The details in the email are not particularly detailed and we are unclear at this stage as to whether it will in fact affect us.
We have a custom scheduled job in Salesforce that generates reports on a quarterly basis. Due to various restrictions around scheduled jobs and the inability to call PageReference.getContent() in certain contexts that existed at the time this process was implemented, it works in a very round about way.
The scheduled job calls a future method that then gets an access token using a HTTP Post to login to an OAuth-Enabled connected app. The POST request includes the grant_type, username, password, client id and client secret in the body of the request in order to login to the connected app and the request is sent to https://login.salesforce.com/services/oauth2/token.
Once we have an access token we include this in authorization header and then call a custom Salesforce Webservice method that actually generates the reports.
We believe this is the only place where any functionality that might be considered a "forced login" is implemented or used in our environment. It is not clear, however, from the information available at the moment whether or not what we are doing counts as a forced login and will not work after the update.
It is also not clear if it does what changes we would need to make in order to ensure this still works after the update.
Does anyone have any more information about this change and whether it is likely to break the way this process works? If so can anyone recommend a better way of doing this? I think I remember reading that many of the restrictions around the usage of PageReference.getContent() have been removed in the past year or two so perhaps it is the case that all this additional complexity is no longer required.
The details in the email are not particularly detailed and we are unclear at this stage as to whether it will in fact affect us.
We have a custom scheduled job in Salesforce that generates reports on a quarterly basis. Due to various restrictions around scheduled jobs and the inability to call PageReference.getContent() in certain contexts that existed at the time this process was implemented, it works in a very round about way.
The scheduled job calls a future method that then gets an access token using a HTTP Post to login to an OAuth-Enabled connected app. The POST request includes the grant_type, username, password, client id and client secret in the body of the request in order to login to the connected app and the request is sent to https://login.salesforce.com/services/oauth2/token.
Once we have an access token we include this in authorization header and then call a custom Salesforce Webservice method that actually generates the reports.
We believe this is the only place where any functionality that might be considered a "forced login" is implemented or used in our environment. It is not clear, however, from the information available at the moment whether or not what we are doing counts as a forced login and will not work after the update.
It is also not clear if it does what changes we would need to make in order to ensure this still works after the update.
Does anyone have any more information about this change and whether it is likely to break the way this process works? If so can anyone recommend a better way of doing this? I think I remember reading that many of the restrictions around the usage of PageReference.getContent() have been removed in the past year or two so perhaps it is the case that all this additional complexity is no longer required.
See Winter Release Notes (http://docs.releasenotes.salesforce.com/en-us/winter16/release-notes/rn_security.htm) for more information.
Since you got the email, you are probably affected, but I can't tell you if that job is the one that might run into this. You might consider filing a case with Salesforce Support.
I actually filed a case with Salesforce directly but they just gave me a generic response about developer support being provided by the community.