Re: Redirection to Other IP Addresses

Hi,

What the guys tend to do as well is have specialized dns server entries
geographically, because everyone typically also gets there DNS server handed
to them from the dns server they are consuming. So at peering stations and
internal to ISP, potentially could have different ips, however,
requires a more co-ordinated approach and local buy-in, unless the consumed
DNS server can be configured and made to server different ips base on
knowledge of the geographical
location of the consuming dns server ip.

This is not a silver bullet of obvious reason aswell.

The other previous proposal I wanted to put forth with regards to redirect
was the following, maybe two could be combined.
Below the previous proposal if you didn't see it. It also looks to address
and provide alternative mechanism to avoid using cookies,
for session tracking.


Wesley Oliver <wesley.olis@gmail.com>
Thu, Jun 13, 9:26 AM
to ietf-http-wg@w3.org
Hi,

I would just like to highlight the following, which I think we could look
at addressing properly and generically across the board.

With regard to the new proposal stand as of march for authentication
session identification,
my understanding is that is drive from the webbrowser client and the server
just accept id provided. It is no longer driven from the server.

I would pref an approach where by it is drive from both client and server,
which means still ensure
that more difficult for hacking, can't just run tought all possible
permutation of client identification tokens and Bruteforce ones way into
end system.

As one of my previous emails to the group was for an approach from driven
from server-side to client-side, which is not that easy to hack and looking
up of session token, versus encryption and description payload, potentially
could be faster, given url and things have max lengths.

Therefore I would like to propose that we look at implemented generic
response forward headers,
which can be used for the server side to client-driven session management
and also for the very old school redirect problems, using the Location
header for security. With microservice was one's single world to handle all
the PCI credit cards and banking information for accounting purposes. It
because increasingly necessary to do handovers into those worlds, to ensure
a high level of security compliance is hand by a single team and all
auditing is in one place for critical information. Which allows design a
generic journey into such infrustature for anyone.

Below is an example of the problems that live everywhere, which we could
generically address with the propose of this simple json self-description
example benefit this line:

Request->Server
Response<-Server
Payload of Repsonse...
Headers: ForwardRequestHeaders
{
RegRequestPathPattern:
{
CrossOrigin: Status.. (explicit) Allow/Deny
Verbs:[Get/Post/Put/Delete/*],
Headers:[
{HeadersKey:HeaderValue},
AuthHeaders:Bearer,
ClientGenerateAuthID:New March Specification(Allow Passing/Deny) (should be
explicit enable only)
]
},
RegRequestPathPattern2:
{
CrossOrigin: Status.. (explicit) Allow/Deny
Verbs:[Get/Post/Put/Delete/*],
Headers:[
{HeadersKey:HeaderValue},
AuthHeaders:Bearer,
ClientGenerateAuthID:New March Specification (Allow Passing/Deny)(should be
explicit enable only)
]
}
}


-------

The insatitial page/api auth redirect, that looks up the subscriptionId and
generates AuthToken,
Then according to the following containing controls will have to perform
the redirect mechanism in the following way.

I would recommend, to avoid being tripped up any browser, react something
not support or being bugged that
We should just support looking for the param in all places, url, query
string, headers, body, form-body submission.
This way we can use the best redirection mechanism possible, that the
client channel supports.

Remember that the url has a limited length, so placing jet tokens, which
can contain a lot more information in the url, can eventually hit the maxim
url length limit.

1. Hand over from different channels to PCI world:

*a. Breakout (Web Browser) (App)*
- Opens Url to instatial page.
- Performs the redirect using url with path, query params. (contents public
visible) url has limited length.
- (Url/Visible) Header:Location URL, can’t specify forward headers, all
must be in the url
- (Url/Visible) HTML meta refresh tag, all in the url
- (Url/Visible) javascript window.location, all must be in the url.
- (Form-Body/Hidden) render a html webpage and then client side generate a
form that is automatically submitted.
- Else render an html webpage and generate a form that is automatically
submitted

- Proxy the request, by acting as pass sought middle man ( but this is not
secure, as opens the door, middle proxy reading the encrypted contents and
fact proxy needs show correct certificate details and spread security now
across many layers, complicating management and much higher risk, not
contained within a single squad, multiple squad have then share security
responsibility.
Therefore, this is not a method that we like to do.

**If the landing page was to redirect again, then the URL/Visible, could be
concealed, because after landing page converted to session state cookie.


*b. WebView( App)*
- Performs the redirect with any one of the methods in a above breakout
(browser)
- (Url+Headers/Hidden)Request from instatitital page/api auth redirect,
which returns the auth information in the Repsonse,
which we then add the information as headers to the web view url open
request, which react supports, to open the page.
** Benefits there are no flashing pages in the redirect  using instatital
pages as for breakout in a above, looks seamless.

*C. ClientBrowser (Online)*
- One of the methods above in a.
- Even if in a frame, the same problems persist.
- The only other approach is to use background request and javascript to
re-write the contents of a html page element place holder, this is a web
app client service side typically type workflow/mechanism approach. ( more
complex)



So I would recommend that if you written a generic landing page that be
able to pulled the specified params from both url path+query string, form
body and headers.

I basically have suggested this for authentication purposes, however, might
as well expanded to to be more generic.
In which can Header:location, can specific request headers under a Repsonse
header called.

ResponseForwardRequestHeaders
{
RegRequestPathPattern:
{
CrossOrigin: Status.. (explicit) Allow/Deny
Verbs:[Get/Post/Put/Delete/*],
Headers:[
{HeadersKey:HeaderValue},
AuthHeaders:Bearer,
ClientGenerateAuthID:New March Specification
]
},
RegRequestPathPattern2:
{
CrossOrigin: Status.. (explicit) Allow/Deny
Verbs:[Get/Post/Put/Delete/*],
Headers:[
{HeadersKey:HeaderValue},
AuthHeaders:Bearer,
ClientGenerateAuthID:New March Specification
]
}
}


Kind Regards,

Wesley Oliver

Kind Regards,

Wesley Oliver

On Mon, Jul 29, 2019 at 9:06 PM Bin Ni <nibin@quantil.com> wrote:

> Yes, what we want is a way to force a "deterministic behavior from the
> client", just like all the 30X redirections today.
>
> Let me give a few more cases in which this can be helpful:
> 1. A client in North America is returned a server IP in Europe by the DNS.
> The server then wants to direct the client to another server in North
> America for better performance.
> 2. The content of a website is hashed to multiple servers based on URL.
> These multiple servers may not even be in the same datacenter. The DNS does
> not have this information and may return any IP to any query of the
> website's hostname.  Each server will calculate the hash for each request
> and redirect client to the correct server that has the content. This is
> quite common for CDN.
>
> Usually this kind of redirection is applied to large objects, where the
> overhead of one more round trip is negligible.
>
> Bin
>
> On Mon, Jul 29, 2019 at 7:48 AM Kyle Rose <krose@krose.org> wrote:
>
>> On Mon, Jul 29, 2019 at 9:46 AM Ben Schwartz <bemasc@google.com> wrote:
>>
>>> On Mon, Jul 29, 2019 at 3:40 AM Oliver, Wesley, Vodacom South Africa
>>> (External) <Wesley.Oliver@vcontractor.co.za> wrote:
>>>
>>>> Hi,
>>>>
>>>> I would like to suggest, that this not be a specific response code,
>>>> like a
>>>> 312 or 302. That it just be a response header, that gets checked by
>>>> Inteligent clients, would then always check for the new address and
>>>> port on which to contact the server,
>>>>
>>>
>>> You're in luck: this is precisely the Alt-Svc header (RFC 7838).  You
>>> can use this today!
>>>
>>> Not all clients currently implement full support for this header, but
>>> hopefully that will improve over time.
>>>
>>
>> I think the issue OP is raising is that they want some deterministic
>> behavior from the client, dictated by the server. Alt-Svc doesn't do this:
>> it's advisory. As a result, it can be used as an optimization, but some
>> kind of load balancer for the original service is still required for
>> clients that do not react to Alt-Svc (should that population be large
>> enough), or when the target Alt-Svc is down. As long as that's within OP's
>> constraints, I agree Alt-Svc is precisely the right solution.
>>
>
>
> --
>
> Bin Ni
> VP of Engineering
> [image: Quantil]
>
> Connecting users with content...it's that simple.
>
> Office: +1-888-847-9851 <(888)%20847-9851>
>
> [image: Tweeter] <https://twitter.com/Team_Quantil>  [image: Google Plus]
> <https://plus.google.com/+Quantil_team/>  [image: Linked In]
> <https://www.linkedin.com/company/quantil>
>
> The information contained in this email may be confidential and/or legally
> privileged. It has been sent for the sole use of the intended recipient(s).
> If the reader of this message is not an intended recipient, you are hereby
> notified that any unauthorized review, use, disclosure, dissemination,
> distribution, or copying of this communication, or any of its contents, is
> strictly prohibited. If you have received this communication in error,
> please reply to the sender and destroy all copies of the message. To
> contact us directly, send to QUANTIL, INC. at 1919 S Bascom Ave #600,
> Campbell, CA 95008
> <https://maps.google.com/?q=1919+S+Bascom+Ave+%23600,+Campbell,+CA+95008&entry=gmail&source=g>,
> or visit our website at www.quantil.com. <https://www.quantil.com/>
>
>

-- 
----
GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.olis@gmail.com