ಪ್ರಸ್ತುತ Electron ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ, ಖಾತೆ-ನಿರ್ದಿಷ್ಟ ಪ್ರತಿ WebContentsView ಗೆ ಅದರದೇ ಹೆಸರಿನ ಸೆಷನ್ ನೀಡಿ. ಅಪ್ಲಿಕೇಶನ್ ಸಿದ್ಧವಾದ ನಂತರ, ಮುಖ್ಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿನ async ಸಹಾಯಕವು ಒಂದು ವೀಕ್ಷಣೆಯನ್ನು ಸಂರಚಿಸಬಹುದು:

const routeSession = session.fromPartition(partitionName);
await routeSession.setProxy({
  mode: 'fixed_servers',
  proxyRules: `http://${proxyHost}:${proxyPort}`,
});
const view = new WebContentsView({
  webPreferences: { session: routeSession },
});
view.webContents.on('login', (event, details, authInfo, callback) => {
  if (!authInfo.isProxy
      || authInfo.scheme.toLowerCase() !== 'basic'
      || authInfo.host !== proxyHost
      || authInfo.port !== proxyPort) return;
  event.preventDefault();
  if (details.firstAuthAttempt) callback(proxyUser, proxyPassword);
  else callback();
});

ಪ್ರತಿ ಪ್ರತ್ಯೇಕ ಖಾತೆಗೆ ಬೇರೆ partitionName ನೀಡಿ ಮತ್ತು ಶ್ರೋತೃ ಚರಗಳನ್ನು ಆ ವೀಕ್ಷಣೆಯ ಸ್ವಂತ closure ನಲ್ಲಿ ಇರಿಸಿ. persist: ಇಲ್ಲದ ಹೆಸರು ಮೆಮೊರಿಯೊಳಗಿನ ಸೆಷನ್ ರಚಿಸುತ್ತದೆ. ಅದೇ ವಿಭಾಗವನ್ನು ಮರುಬಳಕೆ ಮಾಡುವುದು ಅದರ ಸೆಷನ್ ಸ್ಥಿತಿಯನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ.

ವೀಕ್ಷಣೆಯನ್ನು ಇರುವ ವಿಂಡೋಗೆ ಲಗತ್ತಿಸಿ ಮತ್ತು ಅದರ ಪ್ರಾಕ್ಸಿ ಹಾಗೂ ಹ್ಯಾಂಡ್ಲರ್ ಸಿದ್ಧವಾದ ನಂತರವೇ ನ್ಯಾವಿಗೇಟ್ ಮಾಡಿ. ಕೋಡ್ ಪ್ರಸ್ತುತ login ಈವೆಂಟ್ ಒಪ್ಪಂದವನ್ನು ಗುರಿಯಾಗಿಸುತ್ತದೆ, firstAuthAttempt ಸೇರಿದಂತೆ, ಮತ್ತು ತಿರಸ್ಕೃತ ಪುನರಾವರ್ತಿತ ಪ್ರಯತ್ನವನ್ನು ಅದೇ ಖಾತೆಯನ್ನು ಅನಂತವಾಗಿ ಮತ್ತೆ ಕಳುಹಿಸುವ ಬದಲು ರದ್ದುಗೊಳಿಸುತ್ತದೆ.

ಹ್ಯಾಂಡ್ಲರ್ ಸವಾಲು ಉದ್ದೇಶಿತ Basic HTTP ಪ್ರಾಕ್ಸಿಯಿಂದ ಬಂದಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ. ವೆಬ್‌ಸೈಟ್ ಲಾಗಿನ್ ಆ ರುಜುವಾತುಗಳಿಗೆ ಅರ್ಹವಲ್ಲ.

ಪ್ರಾಕ್ಸಿ ನಿಯಮಗಳು ಎಂಡ್‌ಪಾಯಿಂಟ್ ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ; login ಖಾತೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. PAC ಫೈಲ್‌ಗಳು ಮತ್ತು ಕೈಯಿಂದ ಮಾಡಿದ ಪ್ರಾಕ್ಸಿ ನಿಯಮಗಳು ಈ callback ನ ಪಾಸ್‌ವರ್ಡ್ ಅನ್ನು ತಾವೇ ಹೊತ್ತಿರುವುದಿಲ್ಲ.

ಇದು HTTP ಪ್ರಾಕ್ಸಿ ದೃಢೀಕರಣ. ಇದು Chromium ಗೆ SOCKS5 ದೃಢೀಕರಣವನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ. ನಂತರ ಮಾರ್ಗ ಬದಲಾದಾಗ ಇರುವ ಸೆಷನ್ ಸಂಪರ್ಕಗಳಿಗೂ ಅವುಗಳ ಸಾಮಾನ್ಯ ಜೀವನಚಕ್ರ ನಿರ್ವಹಣೆ ಬೇಕು.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು