在代理后面打开 http 连接,需要身份验证但不返回 407

发布于 2024-11-26 13:12:56 字数 257 浏览 3 评论 0原文

我们的小程序位于 Microsoft ISA Server 后面,它集成了代理身份验证。对于没有身份验证凭据的连接,Isa 代理服务器返回 http 405(NOT 407)。这就是我的 java.net。 Authenticator 类不会被调用。 在这种情况下如何验证我与代理服务器的连接?

Applet 使用java1.6 进行签名和编译。 URLConnection 类用于连接。

Our applet is behind Microsoft ISA Server which has integrated proxy authentication.Isa Proxy server returns http 405(NOT 407) for connections which has no authentication credentials on it.There for my java.net.Authenticator class does not get called. how can i authenticate my connections to the proxy server in this situation?

Applet is signed and compiled with java1.6. URLConnection class is used for the connections.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

那小子欠揍 2024-12-03 13:12:56

我可以看到两种解决这个问题的方法,但都不是真正理想的。首先,我猜您已经验证发送带有授权信息的请求不会导致 405 响应代码?如果答案是肯定的,您可以尝试将请求中的 Proxy-authorization 标头设置为标头:

URL url = new URL("http://location");
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setRequestProperty("Proxy-authorization", authorizationValue);

该标头的格式将取决于代理服务器所需的授权方案,因此您必须针对您的特定场景进行一些研究。

第二种方法涉及对内部 JDK 类进行子类化,以欺骗响应代码以强制使用正常的代理身份验证路径。首先,这是子类:

public class HttpURLConnection extends sun.net.www.protocol.http.HttpURLConnection {

    @Override
    public int getResponseCode() throws IOException {
        int code = super.getResponseCode();
        if (code == HTTP_BAD_METHOD) {
            code = HTTP_PROXY_AUTH;
            responseCode = code;
        }
        return code;
    }

}

当然,这将掩盖任何实际的 405 响应,因此可能会产生意想不到的后果。告诉 URL 对象使用此对象需要 java.net.URLStreamHandlerFactory 的子类:

public class URLStreamHandlerFactory extends java.net.URLStreamHandlerFactory {
    @Override
    URLStreamHandler createURLStreamHandler(String protocol) {
        if (!protocol.equals("http")) {
            return null;
        } else {
            return new java.net.URLStreamHandler {
                protected String proxy;
                protected int proxyPort;

                public Handler () {
                    proxy = null;
                    proxyPort = -1;
                }

                public Handler (String proxy, int port) {
                    this.proxy = proxy;
                    this.proxyPort = port;
                }

                @Override
                protected java.net.URLConnection openConnection(URL u) throws IOException {
                        return openConnection(u, (Proxy)null);
                }

                @Override
                protected java.net.URLConnection openConnection(URL u, Proxy p) throws IOException {
                        return new HttpURLConnection(u, p, this);
                }

                @Override
                protected int getDefaultPort() {
                    return 80;
                }

            }
        }
    }
}

然后您可以通过在某处调用 URL.setURLStreamHandlerFactory(new URLStreamHandlerFactory()); 来使用此对象在初始化代码中。我找到了这个网站 此站点对于了解核心 Java 类的工作原理非常有用。如果您需要支持 HTTPS,那么您将需要对该协议进行类似的更改。

希望这些解决方案之一对您有用。我不完全确定后一种方法是否可以在 Applet 的安全限制内发挥作用。前者应该是这样。如果您能够的话,使用不同的 HTTP 库(例如 Apache HttpComponents)也可能更容易做到这一点使用它。

I can see two approaches to working around this problem and neither is really ideal. First, I'm guessing that you've verified that sending the request with the authorization information does not result in a 405 response code? If the answer is yes, you can try setting the Proxy-authorization header in the request as a header:

URL url = new URL("http://location");
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setRequestProperty("Proxy-authorization", authorizationValue);

The format of that header will depend upon the authorization scheme that is required by the proxy server, so you'll have to do some research for your particular scenario.

The second approach involves subclassing an internal JDK class to spoof the response code to force the normal proxy authentication path. First, here is the subclass:

public class HttpURLConnection extends sun.net.www.protocol.http.HttpURLConnection {

    @Override
    public int getResponseCode() throws IOException {
        int code = super.getResponseCode();
        if (code == HTTP_BAD_METHOD) {
            code = HTTP_PROXY_AUTH;
            responseCode = code;
        }
        return code;
    }

}

Of course, this will mask any actual 405 responses so it could have unintended consequences. Telling the URL object to use this requires a subclass of java.net.URLStreamHandlerFactory:

public class URLStreamHandlerFactory extends java.net.URLStreamHandlerFactory {
    @Override
    URLStreamHandler createURLStreamHandler(String protocol) {
        if (!protocol.equals("http")) {
            return null;
        } else {
            return new java.net.URLStreamHandler {
                protected String proxy;
                protected int proxyPort;

                public Handler () {
                    proxy = null;
                    proxyPort = -1;
                }

                public Handler (String proxy, int port) {
                    this.proxy = proxy;
                    this.proxyPort = port;
                }

                @Override
                protected java.net.URLConnection openConnection(URL u) throws IOException {
                        return openConnection(u, (Proxy)null);
                }

                @Override
                protected java.net.URLConnection openConnection(URL u, Proxy p) throws IOException {
                        return new HttpURLConnection(u, p, this);
                }

                @Override
                protected int getDefaultPort() {
                    return 80;
                }

            }
        }
    }
}

Then you can use this object by calling URL.setURLStreamHandlerFactory(new URLStreamHandlerFactory()); somewhere in initialization code. I found this site and this site useful for looking at how the core Java classes work. If you need to support HTTPS then you will need to make similar changes for that protocol.

Hopefully one of these solutions could be useful for you. I'm not completely sure that the latter approach will work inside an Applet's security constraints. The former should though. It is also possible that this might be easier to do with a different HTTP library such as Apache HttpComponents if you are able to use it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文