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 ആപ്ലിക്കേഷനിൽ എത്തിയിട്ടില്ലെന്നതിന് തെളിവല്ല.