Looks like you're trying to do transparent proxying (or "interception proxying", as the Squid FAQ calls it) with authentication.
The Squid FAQ says it pretty clearly:
Can I use ''proxy_auth'' with interception?
No, you cannot. See the answer to the previous question. With interception proxying, the client thinks it is talking to an origin server and would never send the Proxy-authorization request header.
And the "previous question" is:
Why can't I use authentication together with interception proxying?
Interception Proxying works by having an active agent (the proxy) where there should be none. The browser is not expecting it to be there, and it's for all effects and purposes being cheated or, at best, confused. As an user of that browser, I would require it not to give away any credentials to an unexpected party, wouldn't you agree? Especially so when the user-agent can do so without notifying the user [...]
Furthermore, your use case looks more like a reverse proxy, also known as web accelerator, which also adds features like authentication and logging, as the web-server-like application at your http://jarvis:5000 might be deficient at those things.
A transparent proxy is used when the clients need to be able to access basically any web server without requiring any sort of proxy-specific configuration at the browser: the network (typically a router) intercepts and redirects any browser-like connections to the proxy, which then may apply caching to e.g. minimize international traffic, or implement something like malware checking or adult content filtering.
A reverse proxy is only involved with one particular web server, or a group of servers. It may be used to load-balance a group of backend servers, or to add something like authentication or HTTPS to an appliance that only provides unauthenticated HTTP.
If what you actually want is actually more like a reverse proxy, then you might be much better served with using the proxy capabilities of a real web server, since those will give you much better capabilities on HTTP server-side authentication, which seems to be your primary requirement.
With Apache, you might do something like this:
<Location />
AuthType Basic
AuthName "Restricted Service"
# (Following line optional)
AuthBasicProvider file
AuthUserFile "/etc/apache/htpasswd"
Require user me
ProxyPass http://jarvis:5000
ProxyPassReverse http://jarvis:5000
</Location>
and initialize the /etc/apache/htpasswd file with:
# htpasswd -c /usr/local/apache/passwd/passwords me
New password: itsame
Re-type new password: itsame
Adding password for user me
If the server in http://jarvis:5000 embeds links or other references to itself in the HTML it outputs, and those references cannot be adjusted by configuring that server, you might have to play tricks like getting that server listening on the localhost interface only, and Apache in port 5000 of the actual network interface only.
Knowing more about the capabilities of the http://jarvis:5000 server would be important here. If it constructs its responses using whatever hostname and port the client says it used to reach it (the principle of "well, that information got the client connected to me so it must be correct"), then this will be easy. But if it hardcodes its HTML with links to itself using a particular protocol, hostname and port, and those are not configurable, achieving what you want may require trickery with hostnames, or something to edit the URLs in the response HTML in real-time.
