Azure Pipelines ಏಜೆಂಟ್ನ .proxybypass URL ಮಾದರಿಗಳು
ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಿದ Azure Pipelines ಏಜೆಂಟ್ನ ಮೂಲ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ECMAScript ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಗಳನ್ನು ಬಳಸಿ ಮತ್ತು ಕಾರ್ಯದ ಸ್ವಂತ ಪ್ರಾಕ್ಸಿ ಸಂಯೋಜನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ.
ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಿದ Azure Pipelines ಏಜೆಂಟ್ ತನ್ನ ಮೂಲ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿನ .proxybypass ಫೈಲ್ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ಬೈಪಾಸ್ ನಿಯಮಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳಬಹುದು. ಪ್ರತಿ ಸಾಲು URL ನೊಂದಿಗೆ ಹೊಂದಿಸಲಾಗುವ ECMAScript ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಯಾಗಿದೆ.
ಉದಾಹರಣೆಗೆ, ಒಂದು ಆಂತರಿಕ ಫೀಡ್ ಹೋಸ್ಟ್ನ ನಿಯಮವು ಈ ರೀತಿ ಕಾಣಬಹುದು:
^https?://packages[.]internal[.]example(?::[0-9]+)?(?:/|$)
ಅಭಿವ್ಯಕ್ತಿಯು ಆ ಹೋಸ್ಟ್ನ HTTP ಅಥವಾ HTTPS URL ಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ, ಐಚ್ಛಿಕ ಸಂಖ್ಯಾತ್ಮಕ ಪೋರ್ಟ್ನೊಂದಿಗೆ. ಹೋಸ್ಟ್ಹೆಸರಿನ ನಂತರದ ಗಡಿಯು packages.internal.example.other-domain ನಂತಹ ಉದ್ದವಾದ ಹೆಸರಿಗೂ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ತಡೆಯುತ್ತದೆ.
ಇದು ಏಜೆಂಟ್ ಸ್ಥಾಪನೆಯ ಫೈಲ್, ಮೂಲ ಕೋಡ್ ಚೆಕ್ಔಟ್ನಲ್ಲಿ ನಿರಂಕುಶವಾಗಿ ಇರಿಸಿದ ಫೈಲ್ ಅಲ್ಲ. ಇದರ ವಾಕ್ಯರಚನೆಯು ಅಲ್ಪವಿರಾಮದಿಂದ ಬೇರ್ಪಡಿಸಿದ NO_PROXY ಮೌಲ್ಯಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿದೆ. *.internal.example ನಂತಹ ಶೆಲ್ ವೈಲ್ಡ್ಕಾರ್ಡ್ ಅನ್ನು ನಿಯಮಿತ-ಅಭಿವ್ಯಕ್ತಿ ಕ್ಷೇತ್ರಕ್ಕೆ ನಕಲಿಸುವುದು ಅದೇ ಅರ್ಥವನ್ನು ಉಳಿಸುವುದಿಲ್ಲ.
ನಂತರ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಯಾರು ಡೌನ್ಲೋಡ್ ಮಾಡುತ್ತಾರೆ ಎಂಬುದನ್ನು ಗುರುತಿಸಿ
ಏಜೆಂಟ್ನ ಒಳನಿರ್ಮಿತ ಮೂಲ ಮತ್ತು ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಕಾರ್ಯಾಚರಣೆಗಳು ಅದರ ಪ್ರಾಕ್ಸಿ ಸಂರಚನೆಯನ್ನು ಬಳಸುತ್ತವೆ. ಕಾರ್ಯಗಳು ಕಾರ್ಯ ಗ್ರಂಥಾಲಯದ ಮೂಲಕ ಬಹಿರಂಗಗೊಂಡ ಪ್ರಾಕ್ಸಿ ಮಾಹಿತಿಯನ್ನು ಪಡೆದು ತಮ್ಮ ಸ್ವಂತ HTTP ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಅನ್ವಯಿಸಬಹುದು.
ಬಾಹ್ಯ NuGet, dotnet ಅಥವಾ curl ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕರೆಯುವ ಕಾರ್ಯವು ಇನ್ನೊಂದು ಗ್ರಾಹಕನನ್ನು ಸೇರಿಸುತ್ತದೆ. ಆ ಕಾರ್ಯವು ಉಪಕರಣಕ್ಕೆ ಪ್ರಾಕ್ಸಿ ಮತ್ತು ಬೈಪಾಸ್ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಹೇಗೆ ಒದಗಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ದೃಢೀಕರಿಸಿ. ಸರಿಯಾದ ಏಜೆಂಟ್ ನಿಯಮವು ಪ್ರತಿಯೊಂದು ಸ್ವತಂತ್ರ ಪ್ಯಾಕೇಜ್ ಕ್ಲೈಂಟ್ ಅದನ್ನು ಓದಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಆಂತರಿಕ ಫೀಡ್ URL ಅನ್ನು ರೋಗನಿರ್ಣಯ ದಾಖಲೆಯಲ್ಲಿ ಇರಿಸಿ, ಅದರ ಸ್ಕೀಮ್ ಮತ್ತು ಪೋರ್ಟ್ ಸೇರಿದಂತೆ. ಸಂಪರ್ಕಿಸಲಾಗುತ್ತಿರುವ URL ವಿರುದ್ಧ ನಿಯಮವನ್ನು ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಆ ವಿನಂತಿಗೆ ಜವಾಬ್ದಾರವಾದ ಕಾರ್ಯ ಅಥವಾ ಕ್ಲೈಂಟ್ ಸಂರಚನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ.