Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

www.jackpotcitycasino1.com: redirect loop with websteps #1792

Closed
bassosimone opened this issue Sep 30, 2021 · 2 comments · Fixed by ooni/probe-cli#574
Closed

www.jackpotcitycasino1.com: redirect loop with websteps #1792

bassosimone opened this issue Sep 30, 2021 · 2 comments · Fixed by ooni/probe-cli#574
Assignees
Labels
bug Something isn't working data quality

Comments

@bassosimone
Copy link
Contributor

I have been running ./miniooni -n websteps for quite some time and now I noticed it was stuck in a redirect loop with the https://www.jackpotcitycasino1.com/ URL. I am going to investigate either today or soon.

@bassosimone bassosimone added bug Something isn't working effort/S data quality labels Sep 30, 2021
@bassosimone bassosimone self-assigned this Sep 30, 2021
bassosimone added a commit to ooni/probe-cli that referenced this issue Sep 30, 2021
This is the most immediate fix to the issue described by
ooni/probe#1792.

So, the logic was actually miss the increment, which
would have been noticed with proper unit testing.

Anyway, I am not sure why the loop ensues in the first
time. By looking at the headers, it seems we're passing
the headers correctly.

So, even though this fix interrupts the loop, it still
remains the question of whether the loop is legit or
whether we're missing extra logic to properly redirect.
bassosimone added a commit to ooni/probe-cli that referenced this issue Sep 30, 2021
This is the most immediate fix to the issue described by
ooni/probe#1792.

So, the logic was actually miss the increment, which
would have been noticed with proper unit testing.

Anyway, I am not sure why the loop ensues in the first
time. By looking at the headers, it seems we're passing
the headers correctly.

So, even though this fix interrupts the loop, it still
remains the question of whether the loop is legit or
whether we're missing extra logic to properly redirect.
bassosimone added a commit to ooni/probe-cli that referenced this issue Sep 30, 2021
This is the most immediate fix to the issue described by
ooni/probe#1792.

So, the logic was actually miss the increment, which
would have been noticed with proper unit testing.

Anyway, I am not sure why the loop ensues in the first
time. By looking at the headers, it seems we're passing
the headers correctly.

So, even though this fix interrupts the loop, it still
remains the question of whether the loop is legit or
whether we're missing extra logic to properly redirect.
@bassosimone
Copy link
Contributor Author

So, we clearly need to have tests for the code following redirections that take cookies into account. When we have these tests, than we can consider this redirection episode closer. Here's an initial attempt:

package main

import (
	"net/http"
	"time"
)

func handler(w http.ResponseWriter, req *http.Request) {
	cookie, err := req.Cookie("visited")
	if err != nil || cookie.Value != "1" {
		w.Header().Add("Location", "/")
		http.SetCookie(w, &http.Cookie{
			Name:    "visited",
			Value:   "1",
			Expires: time.Now().Add(60 * time.Minute),
		})
		w.WriteHeader(302)
		return
	}
	w.Write([]byte("Welcome, guest\n"))
}

func main() {
	http.HandleFunc("/", handler)
	http.ListenAndServe(":8080", nil)
}

The existing code works fine with this simple redirection. Now I wonder why. Need to investigate more in depth.

@bassosimone
Copy link
Contributor Author

bassosimone commented Oct 1, 2021

So, the insight is that the Accept header we're using is problematic. Here's some evidence:

% curl --resolve 'www.jackpotcitycasino1.com:443:185.31.223.32' -svo/dev/null https://www.jackpotcitycasino1.com/
[snip]
> GET / HTTP/1.1
> Host: www.jackpotcitycasino1.com
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 200 OK
[snip]
< 

Compare to:

% curl -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
    -H 'Accept-Language: en-US;q=0.8,en;q=0.5' \
    -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36'  \
    --resolve 'www.jackpotcitycasino1.com:443:185.31.223.32' \
    -svo/dev/null https://www.jackpotcitycasino1.com/
[snip]
> GET / HTTP/1.1
> Host: www.jackpotcitycasino1.com
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US;q=0.8,en;q=0.5
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
> 
< HTTP/1.1 301 Moved Permanently
[snip]
< Location: https://jackpotcitycasino1.com

Now, let's remove Accept-Language:

% curl -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
    -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36'  \
    --resolve 'www.jackpotcitycasino1.com:443:185.31.223.32' \
    -svo/dev/null https://www.jackpotcitycasino1.com/
[snip]
> GET / HTTP/1.1
> Host: www.jackpotcitycasino1.com
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
> 
< HTTP/1.1 200 OK
[snip]

Let's now use the same Accept-Language header used by the Brave browser:

% curl -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
    -H 'Accept-Language: en-US,en;q=0.9' \
    -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36'  \
    --resolve 'www.jackpotcitycasino1.com:443:185.31.223.32' \
    -svo/dev/null https://www.jackpotcitycasino1.com/
[snip]
> GET / HTTP/1.1
> Host: www.jackpotcitycasino1.com
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.9
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
> 
< HTTP/1.1 200 OK
[snip]

(From my vantage point I cannot say what Web Connectivity would do in this case, because that website is censored in Italy -- and this is why I need to use the --resolve flag above.)

@bassosimone bassosimone removed this from the Sprint 50 - Amphipoda milestone Oct 22, 2021
bassosimone added a commit to ooni/probe-cli that referenced this issue Nov 5, 2021
bassosimone added a commit to ooni/probe-cli that referenced this issue Nov 5, 2021
ainghazal pushed a commit to ainghazal/probe-cli that referenced this issue Mar 8, 2022
This is the most immediate fix to the issue described by
ooni/probe#1792.

So, the logic was actually miss the increment, which
would have been noticed with proper unit testing.

Anyway, I am not sure why the loop ensues in the first
time. By looking at the headers, it seems we're passing
the headers correctly.

So, even though this fix interrupts the loop, it still
remains the question of whether the loop is legit or
whether we're missing extra logic to properly redirect.
ainghazal pushed a commit to ainghazal/probe-cli that referenced this issue Mar 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working data quality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant