ಪ್ರಾಕ್ಸಿ ಮೂಲಕ Ruby Net::HTTP POST ಕಳುಹಿಸಿ

ಫಾರ್ಮ್‌ನ ಗಮ್ಯಸ್ಥಾನವನ್ನು ವಿನಂತಿಯಲ್ಲಿ ಮತ್ತು ಪ್ರಾಕ್ಸಿಯನ್ನು ಸಂಪರ್ಕ ಸಂರಚನೆಯಲ್ಲಿ ಇರಿಸಿ. ನೀವು ಬಯಸುವ URL ಹೊಂದಿರುವ ವಿಶೇಷ ಫಾರ್ಮ್ ಕ್ಷೇತ್ರವನ್ನು ಪ್ರಾಕ್ಸಿಗೆ ಅಗತ್ಯವಿಲ್ಲ, ನಿರ್ದಿಷ್ಟ ವೆಬ್‌ಸೈಟ್‌ನ ವೆಬ್-ಪ್ರಾಕ್ಸಿ ಇಂಟರ್ಫೇಸ್ ಬಳಸುತ್ತಿದ್ದರೆ ಹೊರತುಪಡಿಸಿ.

Ruby ನ Net::HTTP ಗಾಗಿ, ಕ್ಲೈಂಟ್ ರಚಿಸುವಾಗ ಸ್ಪಷ್ಟ HTTP ಪ್ರಾಕ್ಸಿಯನ್ನು ಒದಗಿಸಬಹುದು:

require 'net/http'

uri = URI('https://example.com/form')
http = Net::HTTP.new(uri.hostname, uri.port,
                     '203.0.113.10', 8080)
http.use_ssl = true
http.open_timeout = 5
http.read_timeout = 10
request = Net::HTTP::Post.new(uri.request_uri)
request.set_form_data('message' => 'hello')
response = http.start { |session| session.request(request) }

ಪ್ರಾಕ್ಸಿ ಕೇವಲ ಉದಾಹರಣೆ; ಅನುಮತಿಸಲಾದ ಸಾರ್ವಜನಿಕ ಫಾರ್ಮ್ ಪರೀಕ್ಷೆಗಳಿಗೆ HTTP ಅಭ್ಯರ್ಥಿಗಳು HTTP ಪ್ರಾಕ್ಸಿ ಪಟ್ಟಿಯಲ್ಲಿ ಲಭ್ಯವಿವೆ. ಫಾರ್ಮ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಸಲ್ಲಿಕೆಯನ್ನು ಸ್ವೀಕರಿಸಲು ಉದ್ದೇಶಿಸಿದ ಸೇವೆಯೊಂದಿಗೆ ಬದಲಾಯಿಸಬೇಕು. Net::HTTP ನ ಪ್ರಾಕ್ಸಿ ದಾಖಲೆ ಪ್ರಾಕ್ಸಿ ರುಜುವಾತುಗಳು ಮತ್ತು ಪರಿಸರದಿಂದ ಪಡೆದ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಸಹ ವಿವರಿಸುತ್ತದೆ.

ಪ್ರಾಕ್ಸಿಯನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಓದಿ

ಫಾರ್ಮ್ ತಿರಸ್ಕರಿಸುವ ಸರ್ವರ್ ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಿದ ನಂತರ HTTP ದೋಷವನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಪ್ರತಿಕ್ರಿಯೆ ಸ್ಥಿತಿ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಅಗತ್ಯತೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ: ವಿಧಾನ, ವಿಷಯ ಪ್ರಕಾರ, ಫಾರ್ಮ್ ಕ್ಷೇತ್ರಗಳು, ಕುಕಿಗಳು ಮತ್ತು ಯಾವುದೇ ವಿನಂತಿ ಟೋಕನ್.

ಪ್ರಾಕ್ಸಿ ದೃಢೀಕರಣ ಸವಾಲು ಪ್ರಾಕ್ಸಿಯಿಂದ ಬರುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಲಾಗಿನ್ ಅಥವಾ ತಿರಸ್ಕರಿಸಿದ ಫಾರ್ಮ್ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಸೇರಿದೆ. ಅವುಗಳ ರುಜುವಾತುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಪ್ರಾಕ್ಸಿ ಸಂರಚನೆಗೆ ಗಮ್ಯಸ್ಥಾನದ ಗುಪ್ತಪದವನ್ನು ಸೇರಿಸುವುದು ಗಮ್ಯಸ್ಥಾನದ ಲಾಗಿನ್ ಅನ್ನು ಪೂರೈಸಲಾರದು.

Squid ನ ಫಾರ್ವರ್ಡಿಂಗ್-ಹೆಡರ್ ನಿಯಮಗಳು ಇನ್ನೊಂದು ಸಂಭಾವ್ಯ ಗೊಂದಲದ ಮೂಲ. ಅವುಗಳ ಸರ್ವರ್-ಸೈಡ್ ನೀತಿ ಮಾನ್ಯ Ruby POST ನಿರ್ಮಿಸುವಿಕೆಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿದೆ. ಫಾರ್ಮ್ ಒಮ್ಮೆ ವಿಫಲವಾದ ಕಾರಣಕ್ಕೆ ಹಂಚಿದ ಪ್ರಾಕ್ಸಿಯ ಹೆಡರ್ ನಿಯಮಗಳನ್ನು ಬದಲಾಯಿಸಬೇಡಿ.

ಮರುಪ್ರಯತ್ನಗಳಿಗಾಗಿ, ಮೊದಲ ಸಲ್ಲಿಕೆ ಈಗಾಗಲೇ ಸಂಸ್ಕರಿಸಲ್ಪಟ್ಟಿರಬಹುದೇ ಎಂದು ಪರಿಗಣಿಸಿ. ಕಳೆದುಹೋದ ಪ್ರತಿಕ್ರಿಯೆ POST ಎಂದಿಗೂ ಅಪ್ಲಿಕೇಶನ್ ತಲುಪಲಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ.