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>
0
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.

0

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