OAI / Arazzo-Specification

The Arazzo Specification - A Tapestry for Deterministic API Workflows
https://spec.openapis.org/arazzo/latest.html
Apache License 2.0
200 stars 37 forks source link

redirect_uri does not state TYPE of redirect #261

Open orubel opened 1 day ago

orubel commented 1 day ago

So as we all know from the HTTP standard, there are two types of redirects:

AWS refers to an internal redirect as a step function whereas Spring/Springboot refers to it as a 'forward'

Several other languages and frameworks properly implement the HTTP standard for this as well (basically any multithreaded application with a front controller)

But it seems to you all are only implementing an EXTERNAL REDIRECT which seems to target only single threaded applications like Node.js which are only a partial implementation of the HTTP standard for redirection.

Is this the case with this standard or are you planning to support the HTTP standard fully by implementing internal redirection?

handrews commented 23 hours ago

@orubel RFC9110 does not use the terms "external redirect" or "internal redirect." Could you please restate your point in RFC9110 terminology?

orubel commented 22 hours ago

@handrews Please read entire spec. It is discussed in multiple places:

"The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the knowledge or permission of message senders. Network intermediaries are indistinguishable (at a protocol level) from an on-path attacker, often introducing security flaws or interoperability problems due to mistakenly violating HTTP semantics.

For example, an "interception proxy" [RFC3040] (also commonly known as a "transparent proxy" [RFC1919]) differs from an HTTP proxy because it is not chosen by the client. Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate firewalls to enforce network usage policies."

These are a violation ONLY when standard is badly implemented (note the keyword being 'mistakenly' violating HTTP semantics)):

Spring Boot forwarding itself isn't inherently a violation of HTTP, but it can be depending on how it's implemented. Here's why: When forwarding, developers might not set the correct HTTP status code. This can lead to confusion for clients and tools that rely on these codes.

Security Concerns: If not implemented carefully, forwarding can expose internal URLs or sensitive information.This requires RBAC/ABAC rules (see OWASP top 10)

Use Redirects When Appropriate: For user-facing scenarios, use redirects (301, 302) instead of forwarding whenever possible. This ensures that the client is aware of the change in URL.

Set Proper Status Codes: If you must forward, ensure that the correct HTTP status code is set (e.g., 404 for not found, 500 for internal server errors). Secure Sensitive Information: Avoid forwarding requests to URLs that expose sensitive data or internal application logic.

I use the term 'internal redirect' as there is not standard name. It is called a loopback/forward/internal direct by varying frameworks but the functionality is the same regardless of framerwork or language in the fact that a front controller in the app handles the original request as well as redirection without it going outside the DMZ.

handrews commented 22 hours ago

@orubel I've read the entire spec (2616, the 723xs, the 911xs) multiple times over the years. It is not reasonable to assume that people know terminology that you acknowledge you made up yourself. I'll let others handle this issue.

orubel commented 22 hours ago

@handrews You are being rude. Please state what I have made up or cease being rude. This is not appropriate behaviour for a maintainer and contributor.

handrews commented 22 hours ago

@orubel from the email (and edit history) of your previous comment:

I use the term 'internal redirect' as there is not standard name. It is called a loopback/forward/internal direct by varying frameworks but the functionality is the same regardless of framerwork or language in the fact that a front controller in the app handles the original request as well as redirection without it going outside the DMZ.

@frankkilcommins @OAI/tsc I'm bowing out here.

orubel commented 22 hours ago

@handrews https://www.google.com/search?q=internal+redirect&oq=internal+redirect&gs_lcrp=EgZjaHJvbWUyDggAEEUYORhDGIAEGIoFMg0IARAAGJECGIAEGIoFMgwIAhAAGBQYhwIYgAQyDQgDEAAYkQIYgAQYigUyDAgEEAAYFBiHAhiABDIICAUQABgWGB4yBggGEEUYPDIGCAcQRRg80gEIMzQzOWowajeoAgiwAgE&sourceid=chrome&ie=UTF-8

Seems to exist without me ... thougg if you want to give me credit, I'm complimented.

If you are unfamiliar with the term or its many various names (such as forward or loopback) and how it works, there is no need to lash out. I would prefer a polite conversation. Now can we go back to being polite, please?

Seriously, if AWS and Spring and Django and Node.js are doing this, it should not come down to someone saying another professional is 'making this up'. This is unprofessional

microapiframework commented 15 hours ago

@handrews was not rude or unprofessional or lashing out.

@orubel I can't help but notice you are going out of your way to instigate arguments with your comments. For example "The entire solution is half-assed, insecure and partial implementation" isn't exactly a professional friendly tone either. If you don't want to help further the spec in a positive manner why bother participating? Please feel free to find other projects to participate in if you are not satisfied with this one.

orubel commented 15 hours ago

@microapiframework "It is not reasonable to assume that people know terminology that you acknowledge you made up yourself." That doesn't seem rude? Please explain how that statement is politely accusing someone of making things up when we are discussing standards. I would like to know how accusing someone of making something up when that person is using each communities terminology for the HTTP implementation (since there is no standardized terminology provided). Hence why I referenced each frameworks terminology (spring/forward, aws/step functions, nodejs/loopback and others/internal redirect)

If someone is unclear or I does not understand, I do not accuse them of 'making things up'. I simply ask a question.

In this situation, you might be choosing not enforce your ethical standards and thats your choice but just don't delete this post. Make sure people can see this behaviour is normalized in the community.

Secondly, this isn't argumentative until you tried to defend this behaviuour. I laid out facts, pointed to urls. If they are not clear, please ask questions and I will point to additional information or even provide diagrams. This is how an exchange of information takes place and I am more than happy to do so.