From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A979C1381F3 for ; Mon, 20 May 2013 04:31:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 165ADE08FB; Mon, 20 May 2013 04:31:34 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C90D0E08D5 for ; Mon, 20 May 2013 04:31:32 +0000 (UTC) Received: from mail-vc0-f174.google.com ([209.85.220.174]:54828) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1UeHky-002WEu-NO for Gentoo-user@lists.gentoo.org; Mon, 20 May 2013 11:31:32 +0700 Received: by mail-vc0-f174.google.com with SMTP id hr11so4901814vcb.5 for ; Sun, 19 May 2013 21:31:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=4UscidLZuPptYszTwDXHYYRrB1bTU7s70JDWq9Ym3qU=; b=dOCHyNONUo8jPffH/I65Lrcnsun0fRp+t8aou4bXGuqjB09KvNEbxnwfuYDcaEc5+H VHu1qnxMSeZE3kDPMaLctenkaUXiD2kIOZP8aSzaCrLjmJvuw3NvWGgaX1WKjPnU7kRV oH7BwowfIfWLHWf/hRY5O3AAuu06yKude2fxXwp2lSo2Z56QOEhBJGH3ITIoOpfSZNNQ Yc9D6xpot+3egeDNxWe4Qx+5N/LP++1vPUBME90RicO/rnOpuI3TtkYj7wvcOb1JgfjE MtrKQeuFjAY7A1frPDwQ9RB/yzep9cQzdhAp43QKZqbEPr75gzaVXf0xtp7aHumvgM7A 2zSQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.220.176.71 with SMTP id bd7mr33062260vcb.12.1369024291258; Sun, 19 May 2013 21:31:31 -0700 (PDT) Received: by 10.220.192.70 with HTTP; Sun, 19 May 2013 21:31:31 -0700 (PDT) Received: by 10.220.192.70 with HTTP; Sun, 19 May 2013 21:31:31 -0700 (PDT) Date: Mon, 20 May 2013 11:31:31 +0700 Message-ID: Subject: [gentoo-user] Lightweight & Simple Proxy that supports upstream authentication From: Pandu Poluan To: gentoo-user Content-Type: multipart/alternative; boundary=001a11c1c27891fd5404dd1ece90 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Get-Message-Sender-Via: svr-us4.tirtonadi.com: authenticated_id: rileyer+pandu.poluan.info/only user confirmed/virtual account not confirmed X-Archives-Salt: b343157d-8dc6-431e-9da1-e67c0f0213f9 X-Archives-Hash: 5e2c9f0d2613c89d917d1ac645e775d4 --001a11c1c27891fd5404dd1ece90 Content-Type: text/plain; charset=UTF-8 Hello, I'm looking for a simple HTTP+FTP proxy that supports upstream authentication. The reason is that we (that is, my employer) have a server that requires Internet access for its setup, but for some reason* my employer does not want to give the contractors a login for the corporate proxy. I'm planning of setting up a simple proxy to authenticate against the corporate proxy using one of my credentials, and have the contractor use this simple proxy instead of the corporate one. I think Squid can do that... but is there a simpler solution? I truly don't need caching, inter-proxy coordination, or other exotic stuff. Just a way to allow other people to authenticate against the corporate proxy using my credentials, but without giving my credentials away. (Of course the simple proxy will be installed on a totally separate system, one under my full control and nobody else's) Rgds, -- --001a11c1c27891fd5404dd1ece90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

I'm looking for a simple HTTP+FTP proxy that supports upstream authe= ntication.

The reason is that we (that is, my employer) have a server that requires= Internet access for its setup, but for some reason* my employer does not w= ant to give the contractors a login for the corporate proxy.

I'm planning of setting up a simple proxy to authenticate against th= e corporate proxy using one of my credentials, and have the contractor use = this simple proxy instead of the corporate one.

I think Squid can do that... but is there a simpler solution? I truly do= n't need caching, inter-proxy coordination, or other exotic stuff. Just= a way to allow other people to authenticate against the corporate proxy us= ing my credentials, but without giving my credentials away.

(Of course the simple proxy will be installed on a totally separate syst= em, one under my full control and nobody else's)

Rgds,
--

--001a11c1c27891fd5404dd1ece90--