0

I have tried both the below approaches, but still I see only "SESSION_ID_REMOVED" in the debug statements. When I schedule the batch from Developer console, I am getting the "SESSION_ID_REMOVED" in the debug statements.

Can anyone please let me know what was wrong with the below approaches and a potential solution.

Appreciate your help..

Approach 1:

global class BAT_Agreement implements  Schedulable {
    private String sessionId;
    global BAT_Agreement(String sessionId ) {
        this.sessionId = sessionId;  
    }

    global void execute(SchedulableContext sc) {
        String newsessionId = Page.SessionIDHack.getContent().toString();
        System.debug('newsessionId==>' + newsessionId ); // Printed as "SESSION_ID_REMOVED"
        System.debug('sessionId==>' + sessionId ); // Printed as "SESSION_ID_REMOVED"        
    }
}

String sch = '0 56 19 * * ?';
String jobID = System.schedule('MOVE AGREEMENT', sch, new BAT_Agreement((UserInfo.getSessionId())));

Approach 2:

public class QueueAgreement implements Queueable , Database.AllowsCallouts{
   private String sessionId = null; 
    public void execute(QueueableContext context) {
    sessionId = Page.SessionIDHack.getContent().toString();  
        System.debug('sessionId==>' + sessionId); // Printed as "SESSION_ID_REMOVED"   
    }
}

QueueAgreement job = new QueueAgreement() ;
System.enqueueJob(job);

VF page:

<apex:page contentType="text/plain" >{!$Api.Session_Id}</apex:page>
5

First, you can't debug the session ID, because it is protected from being debugged on purpose as a security restriction. If you're seeing that message, that means you have a valid session Id.

Second, this "hack" is no longer necessary. In API version 44.0 and higher, UserInfo.getSessionId() now works in asynchronous code.

Not the answer you're looking for? Browse other questions tagged or ask your own question.