Score:0

เหตุใดฉันจึงเขียน URL ชุดเดียวได้ แต่เขียนชุดอื่นด้วย NGINX ไม่ได้

ธง in

ฉันได้ตั้งค่า NGINX เวอร์ชัน 1.18.0 เป็นพร็อกซีย้อนกลับสำหรับการติดตั้ง Apache Superset 1.4.0 ของฉันแล้ว

ฉันกำลังพยายามจับภาพรูปแบบ URL และ เขียนใหม่ โดยการเพิ่ม สแตนด์อโลน = 1 ในตอนท้าย

การกำหนดค่า NGINX ต่อไปนี้ทำงานตามที่คาดไว้:

ที่ตั้ง /superset/สำรวจ/ {
        ถ้า ($args ~* "(.*?)slice_id%22%3A133(.*)$") {
            เขียนใหม่ ^/superset/explore/(.*)$ /superset/explore/$1?standalone=1 break;
        }

        proxy_pass http://127.0.0.1:8087;
        proxy_set_header โฮสต์ $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-ส่งต่อ-สำหรับ $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

เพราะเมื่อฉันเยี่ยมชม (ด้วย Chrome) URL เช่น http://192.168.239.40:8088/superset/explore/?form_data=%7B%22viz_type%22%3A%22echarts_timeseries_line%22%2C%22datasource%22%3A%2233__table%22%2C%22slice_id%22%3A133% ทูซี ...ฉันเห็นว่ามันถูกแทนที่ด้วยเครื่องหมายบวกเดิม &สแตนด์อโลน=1 เพิ่มไปยัง URL เมื่อฉันตรวจสอบแถบที่อยู่ของ Chrome

แต่เมื่อฉันพยายามทำสิ่งที่คล้ายกันสำหรับรูปแบบ URL อื่นสำหรับ Apache Superset เช่นต่อไปนี้:

   ตำแหน่ง /แดชบอร์ด/รายการ/ {
        เขียนใหม่ ^/dashboard/list/(.*)$ /dashboard/list/$1?standalone=1 break;

        proxy_pass http://127.0.0.1:8087;
        proxy_set_header โฮสต์ $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-ส่งต่อ-สำหรับ $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

และฉันขอ http://192.168.239.40:8088/dashboard/list/ ด้วย Chrome ฉันเห็นแถบที่อยู่แทนที่ด้วย http://192.168.239.40:8088/dashboard/list/?pageIndex=0&sortColumn=changed_on_delta_humanized&sortOrder=desc&viewMode=table แต่ฉันไม่เห็นอะไรเลย &สแตนด์อโลน=1 ต่อท้าย

ฉันยังตรวจสอบบันทึกของ Superset เพื่อดูว่ามันทำหน้าที่อะไรหลังจากที่ฉันขอ http://192.168.239.40:8088/dashboard/list/ และฉันเห็นว่า ?สแตนด์อโลน=1 ถูกต่อท้ายจริง!

10 ก.พ. 14:09:19 หลามเซิร์ฟเวอร์แดชบอร์ด[34169]: 2022-02-10 14:09:19,482:INFO:werkzeug:127.0.0.1 - - [10/ก.พ./2022 14:09:19] "รับ / แดชบอร์ด/รายการ/?สแตนด์อโลน=1 HTTP/1.0" 200 -
10 ก.พ. 14:09:20 หลามเซิร์ฟเวอร์แดชบอร์ด[34169]: 2022-02-10 14:09:20,729:INFO:werkzeug:127.0.0.1 - - [10/ก.พ./2022 14:09:20] "GET / api/v1/dashboard/_info?q=(keys:!(สิทธิ์)) ​​HTTP/1.0" 200 -
10 ก.พ. 14:09:20 หลามเซิร์ฟเวอร์แดชบอร์ด[34169]: 2022-02-10 14:09:20,771:INFO:werkzeug:127.0.0.1 - - [10/ก.พ./2022 14:09:20] "GET / api/v1/dashboard/?q=(order_column:changed_on_delta_humanized,order_direction:desc,page:0,page_size:25) HTTP/1.0" 200 -

ความคิดใด ๆ ว่าทำไมสิ่งนี้ถึงเกิดขึ้น?

ที่สมบูรณ์ /etc/nginx/conf.d/superset.conf มีดังนี้

เซิร์ฟเวอร์ {
    ฟัง 8088;
    server_name 192.168.239.40;

    ที่ตั้ง / {
        proxy_pass http://127.0.0.1:8087;
    }

    ที่ตั้ง /superset/สำรวจ/ {
        ถ้า ($args ~* "(.*?)slice_id%22%3A133(.*)$") {
            เขียนใหม่ ^/superset/explore/(.*)$ /superset/explore/$1?standalone=1 break;
        }

        proxy_pass http://127.0.0.1:8087;
        proxy_set_header โฮสต์ $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-ส่งต่อ-สำหรับ $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

   ตำแหน่ง /แดชบอร์ด/รายการ/ {
        เขียนใหม่ ^/dashboard/list/(.*)$ /dashboard/list/$1?standalone=1 break;

        proxy_pass http://127.0.0.1:8087;
        proxy_set_header โฮสต์ $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-ส่งต่อ-สำหรับ $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }


    # จำเป็นเนื่องจาก superset มี URL เส้นทางฐานที่ฮาร์ดโค้ด
    ตำแหน่ง / คงที่ / {
        proxy_pass http://127.0.0.1:8087/static/;
    }

    # เพื่อแสดงแดชบอร์ดเฉพาะโดยใช้ URL ที่กำหนดเอง
    # ตัวอย่างด้านล่างจะทำให้แดชบอร์ด 2 พร้อมใช้งานในโหมดสแตนด์อโลน
    # บน $host/dashboards/my-dashboard
    ตำแหน่ง /แดชบอร์ด/แดชบอร์ดของฉัน {
        proxy_pass http://127.0.0.1:8087/superset/dashboard/2/?standalone=true;
    }
}
Score:1
ธง us

URL ที่ยุ่งเหยิงเช่นนี้ค่อนข้างอันตรายหากไม่ทราบรายละเอียดว่าแอปพลิเคชันอัปสตรีมจัดการกับ URL อย่างไร สิ่งนี้สามารถนำไปสู่ข้อผิดพลาดที่ยากต่อการวินิจฉัย

คุณควรทบทวนเป้าหมายเดิมและคิดว่าคุณสามารถบรรลุเป้าหมายด้วยวิธีอื่นได้หรือไม่

สิ่งที่เกิดขึ้นกับปัญหาปัจจุบันของคุณ: เขียนใหม่ ... ทำลาย เป็นการเขียน URL ใหม่ภายใน ซึ่งหมายความว่า nginx จะแก้ไข URL ที่ส่งไปยังเซิร์ฟเวอร์อัปสตรีมเท่านั้น

ในกรณีนี้ เซิร์ฟเวอร์อัพสตรีมของคุณจะส่งกลับหน้าที่ระบุโดย URL ที่แก้ไข

ในเบราว์เซอร์ของไคลเอนต์ ไม่มีการเปลี่ยนแปลงใน URL เนื่องจากเซิร์ฟเวอร์เพิ่งส่งคืนเนื้อหาสำหรับ URL ที่ร้องขอ

สิ่งที่เกิดขึ้นกับกรณีที่ URL ของเบราว์เซอร์เปลี่ยนแปลงด้วยการกำหนดค่านี้: ในกรณีนั้น ดูเหมือนว่าแอปพลิเคชันอัปสตรีมของคุณจะตอบสนองด้วยการเปลี่ยนเส้นทาง 302 ที่ทำให้เบราว์เซอร์ไปที่ URL อื่น

หากคุณต้องการบอกไคลเอนต์ให้ไปที่ URL คุณต้องส่งการเปลี่ยนเส้นทาง HTTP:

เขียนใหม่ ^/dashboard/list/(.*)$ /dashboard/list/$1?standalone=1;

อย่างไรก็ตาม สิ่งนี้มักจะสร้างการวนซ้ำการเปลี่ยนเส้นทางด้วยตัวเอง เนื่องจากเหมือนกัน ที่ตั้ง บล็อกจับคำขอครั้งแล้วครั้งเล่า การสร้างการเปลี่ยนเส้นทาง HTTP แบบไม่วนซ้ำอาจกลายเป็นแบบฝึกหัดที่ค่อนข้างซับซ้อน

ดังนั้นฉันจะมองหาทางเลือกอื่นในการแก้ปัญหาที่เกิดขึ้นจริง

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา