Ruby Net::HTTP POST-ის გაგზავნა პროქსის მეშვეობით
დააყენეთ Ruby HTTP კავშირი ცხადი პროქსით, შემდეგ გაგზავნეთ ფორმის მონაცემები დანიშნულების ადგილზე.
ფორმის დანიშნულება მოთხოვნაში დატოვეთ, პროქსი კი — კავშირის კონფიგურაციაში. პროქსის არ სჭირდება სპეციალური ფორმის ველი თქვენთვის სასურველი 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 აპლიკაციას არასოდეს მიუღწევია.