Πιστεύετε πως 1 πίνακας ειναι λίγος γι αυτό το feature που θέλω να κάνω;

[PC_MAGAS]

Αναπτύσσω το https://github.com/pc-magas/http-manipulator  σαν προσωπικό project, και είναι ένας No-code http-manipulator με αποτερο σκοπο να σνιφάρει και να τροποποιεί http incomming calls. Η ιδέα ειναι να μπαίνει σαν reverse-proxy και να:

1. Προσωμοιώνει γνωστές υπηρεσίες sms/email/crm που δεν έχουν sandbox η πρέπει να περάσεις 40 κύμματα για να πάρεις.
2. Να τροποποιεί http streams των παραπάνω υπηρεσιών πχ αλλαγή παραλήπτη για SMS
3. Να προωθεί σε low-level εισερχόμενα http requests σε άλλη ip.
4. να βλέπεις live οποιαδήποτε κίνηση λαμβάνεις σε real time.

 

Το πρώτο feature το οποίο κάνω είναι το http redirection. Αυτό θα παίζει σε 2 modes:

1. Http -> https
2. Οποιοδήποτε άλλου τύπου

Και για τα 2 έχω αυτό το table https://github.com/pc-magas/http-manipulator/blob/f35ef49bee489c8cae919231f09380d248713b83/src/common/db.js#L14-L25

Και αξιοποιώ αυτό το logic https://github.com/pc-magas/http-manipulator/blob/f35ef49bee489c8cae919231f09380d248713b83/src/manipulators/redirect.js#L3-L55

Όμως κάτι δεν μου κολλά το να έχω 1 table και για τα 2 είδη redirect και φοβάμαι ότι θα καταλήξει να είναι πονοκέφαλος στο maintain.

Έτσι θα ήθελα την γνώμη σας γι αυτό πιστ εύετε πως για εκάστοτε τύπο redirect να έχω 2 ή 1 table;

 

Σχεδιαστικά η εφαρμογή έχει 2 μέρη το controll panel που ακούει σε μια ξεχωριστή θύρα εκτός τις 80 και 449 και τον manipuilator που θα ακούει στις θύρες 80 και 449.

Και τα 2 θα είναι σε ένα single blob που θα containorποιηθεί και το κάνω γι απλότητα θυσιάζοντας την ταχύτητα. Η ιδέα ειναι να είναι ένα έξτρα tool που θα μπαίνει σε τοπικό επίπεδο μπροστα απο τον nginx και όλες οι εφαρμογές που θα επικοινωνούν θα το κάνουν μέσω του manipulator, ώστε ναι μεν να εισάγω Bottleneck αλλά στον αντίποδα να ξέρω τι καλείτε και από που.

Επεξ/σία 14 Φεβρουαρίου 2023 από PC_MAGAS

[kaliakman]

14 ώρες πριν, PC_MAGAS είπε

Αναπτύσσω το https://github.com/pc-magas/http-manipulator  σαν προσωπικό project, και είναι ένας No-code http-manipulator με αποτερο σκοπο να σνιφάρει και να τροποποιεί http incomming calls. Η ιδέα ειναι να μπαίνει σαν reverse-proxy και να:

1. Προσωμοιώνει γνωστές υπηρεσίες sms/email/crm που δεν έχουν sandbox η πρέπει να περάσεις 40 κύμματα για να πάρεις.
2. Να τροποποιεί http streams των παραπάνω υπηρεσιών πχ αλλαγή παραλήπτη για SMS
3. Να προωθεί σε low-level εισερχόμενα http requests σε άλλη ip.
4. να βλέπεις live οποιαδήποτε κίνηση λαμβάνεις σε real time.

 

Το πρώτο feature το οποίο κάνω είναι το http redirection. Αυτό θα παίζει σε 2 modes:

1. Http -> https
2. Οποιοδήποτε άλλου τύπου

Και για τα 2 έχω αυτό το table https://github.com/pc-magas/http-manipulator/blob/f35ef49bee489c8cae919231f09380d248713b83/src/common/db.js#L14-L25

Και αξιοποιώ αυτό το logic https://github.com/pc-magas/http-manipulator/blob/f35ef49bee489c8cae919231f09380d248713b83/src/manipulators/redirect.js#L3-L55

Όμως κάτι δεν μου κολλά το να έχω 1 table και για τα 2 είδη redirect και φοβάμαι ότι θα καταλήξει να είναι πονοκέφαλος στο maintain.

Έτσι θα ήθελα την γνώμη σας γι αυτό πιστ εύετε πως για εκάστοτε τύπο redirect να έχω 2 ή 1 table;

 

Σχεδιαστικά η εφαρμογή έχει 2 μέρη το controll panel που ακούει σε μια ξεχωριστή θύρα εκτός τις 80 και 449 και τον manipuilator που θα ακούει στις θύρες 80 και 449.

Και τα 2 θα είναι σε ένα single blob που θα containorποιηθεί και το κάνω γι απλότητα θυσιάζοντας την ταχύτητα. Η ιδέα ειναι να είναι ένα έξτρα tool που θα μπαίνει σε τοπικό επίπεδο μπροστα απο τον nginx και όλες οι εφαρμογές που θα επικοινωνούν θα το κάνουν μέσω του manipulator, ώστε ναι μεν να εισάγω Bottleneck αλλά στον αντίποδα να ξέρω τι καλείτε και από που.

Γιατί χρειάζεσαι όλα αυτά τα πεδία στο table? "From", "to"  άντε και method  δεν φτάνουν;

[PC_MAGAS]

6 ώρες πριν, kaliakman είπε

Γιατί χρειάζεσαι όλα αυτά τα πεδία στο table? "From", "to"  άντε και method  δεν φτάνουν;

 

1. Tα πεδία use_in_http και use_in_https ειναι για να ορίζω redirects είτε μέσω του http port είτε μέσω του https port. To πρόγραμμα κάνει listen και στο http και στο https την ίδια στιγμή. θέλω να μπορώ να λέω ότι το redirect αν το response θα είναι για requests που έχρονται είτε μέσω http είτε μέσω https.
2. Το πεδίο http_status_code λέει τι status code θα επιστρέφει. Βάση του https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections δεν είναι to 301 και 302 status code.
3. To πεδίο exact_match έχει το εξής functionality:
   1. Αν είναι 0 (false) ποιάνει όλα τα paths πχ αν λαμβάνω το http://example.com θα κάνει redirect και στο http://example.com/test
   2. Αν είναι 1 (true) τότε θα πρέπει πχ αν λαμβάνω το http://example.com θα κάνει redirect μονο στο http://example.com και όχι στο http://example.com/test

Για το redirect έχω 2 οθόνες ρυθμίσεως (Βλ attatched οθόνες):

1. Advanced redirecting
   
2. Basic http to https redirecting
   

Και με το table καλύπτω και τις 2 περιπτώσεις.

 

Τώρα που το σκέφτομαι μάλλον θα πρέπει να το δω καλύτερα με wirdcard η regex matchers όσο αφορά το exact match.

 

 

[ΠάρηςΓ]

Στις 15/2/2023 στις 8:45 ΜΜ, PC_MAGAS είπε

 

1. Tα πεδία use_in_http και use_in_https ειναι για να ορίζω redirects είτε μέσω του http port είτε μέσω του https port. To πρόγραμμα κάνει listen και στο http και στο https την ίδια στιγμή. θέλω να μπορώ να λέω ότι το redirect αν το response θα είναι για requests που έχρονται είτε μέσω http είτε μέσω https.
2. Το πεδίο http_status_code λέει τι status code θα επιστρέφει. Βάση του https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections δεν είναι to 301 και 302 status code.
3. To πεδίο exact_match έχει το εξής functionality:
   1. Αν είναι 0 (false) ποιάνει όλα τα paths πχ αν λαμβάνω το http://example.com θα κάνει redirect και στο http://example.com/test
   2. Αν είναι 1 (true) τότε θα πρέπει πχ αν λαμβάνω το http://example.com θα κάνει redirect μονο στο http://example.com και όχι στο http://example.com/test

Για το redirect έχω 2 οθόνες ρυθμίσεως (Βλ attatched οθόνες):

1. Advanced redirecting
   
2. Basic http to https redirecting
   

Και με το table καλύπτω και τις 2 περιπτώσεις.

 

Τώρα που το σκέφτομαι μάλλον θα πρέπει να το δω καλύτερα με wirdcard η regex matchers όσο αφορά το exact match.

 

 

Οταν λες ειδη εννοεις για το exact match; Λογικα οπως ειπες θα μπορουσες να βαλεις κατι σα το nginx  https://nginx.org/en/docs/http/ngx_http_core_module.html#location .

Βεβαια μετα δε θα μπορεις να βαρας queria στη βαση με regex τετοιου τυπου αλλά ακομα και 100 τετοια να εχεις δεν ειναι τιποτα για ενα συχρονο υπολογιστη.

Δε ξερω αν ειναι καλυτερο να βαλεις καποιο module sqlite-regex  η να τα υπολογιζεις on the fly.

[PC_MAGAS]

12 ώρες πριν, ΠάρηςΓ είπε

Οταν λες ειδη εννοεις για το exact match; Λογικα οπως ειπες θα μπορουσες να βαλεις κατι σα το nginx  https://nginx.org/en/docs/http/ngx_http_core_module.html#location .

Βεβαια μετα δε θα μπορεις να βαρας queria στη βαση με regex τετοιου τυπου αλλά ακομα και 100 τετοια να εχεις δεν ειναι τιποτα για ενα συχρονο υπολογιστη.

Δε ξερω αν ειναι καλυτερο να βαλεις καποιο module sqlite-regex  η να τα υπολογιζεις on the fly.

Exact match εννοώ ότι σε μια εγγραφή όπως https://google.com αν το exact_match είναι false uα ταιρίαζει με oποιοδήποτε path ειδάλλως θα ταιριάζει μόνο με το https://google.com.

 

[spoler]Μάλλον θέλει redisign to feature αυτό[/spoiler]

Επεξ/σία 17 Φεβρουαρίου 2023 από PC_MAGAS