I am new with Squid, currently i have successfully setup basic authentication using external ACL to validate username and password. This works great, but I want to have a custom login page "HTML based" to authenticate a user.
Currently this is my setting that works:
auth_param basic program /usr/bin/php ./app.php
external_acl_type tcgloginhelper ttl=1800 %SRC %LOGIN %{Proxy-Authorization} /usr/bin/php ./app.php
acl tcglogin external tcgloginhelper
http_access allow tcglogin
Is it possible to have a custom html login page? How can this be done?
Is it possible to configure a custom login page to SQUID?
No. Squid uses the RFC-style Proxy-Authorization header. It gets a HTTP
code 407 from the proxy and after a successful authentication delivers
the header with every request. You would need to change both the proxy
and the browser.
http://www.squid-cache.org/mail-archive/squid-users/200509/0251.html
Related
I know nginx provide a way to login using basic authentication (with a password file). I wanted to know if there is a way to delegate the authentication to a dedicated server.
Here is the process I want to pursue :
- The user try to access to the nginx server without auth.
- Nginx ask for username and password.
- Nginx request the dedicated server with the provided credentials.
- If ok, nginx create a new basic auth for the user, and let the user pass in.
Thank you
As I know browser login user nginx basic authentication server with -H 'Authorization: Basic username:password' header.
But in case of my application, the client uses command lines calling REST API, which I can't modify. So there is no way for me to inject user credential in the header. The question is how nginx server to be configured to remember user, and allow user to log out without credential sent in every request?
For example, user types commands from terminal:
login myhost.com -u myname:mypassword
then this user is authorized to access the sever, he/she can retrieve information by provided APIs.
logout myhost.com
then this user logs out.
I've written my own login app to protect my api following the oauth-login-app example.
I've implemented the web server flow and everything works great.
My question is: how should I handle an authentication failure at step 3? How do I tell he client app that the authentication failed? The user could either press the cancel button, or refuse permission or just enter the wrong details.
When you initiate OAuth 2.0 (dance) with
/authorize
the user-agent land on /login page (created/hosted by you),
post redirect.
enduser(user-agent) submits the username/password
to the page hosted by you. Here you collect the credentials and
submit to Apigee, and if authentication fails, send a HTTP 401
response. Now your application should be in position to re-render
the login page and with a flash "invalid credential".
Now coming to if user is authenticated but rejects the authorization request in
consent page, you should redirect to the "redirect_uri" provided
by client, with error code.
How do I tell he client app that the authentication failed?
The login app will redirect the control back to the application redirect URI - with added error code/description in the URL as hash parameters. In case of success the URL is appended with code or token.
You can do this redirect from your login app directly but I would suggest to make the redirect call first to an Apigee Proxy and let Apigee Proxy send the redirect back to app. Both in case of success and failure. In this way you will have the benefit of using Apigee analytics that helps your understand how many OAuths failed for what reason etc.
EDIT:
You can use the same GenerateAuthorizationCode proxy you have built for the success flow. When login fails or succeeds, in either case you need to pass that information to this proxy. Generally the login app and this proxy should share this information using a common session store. You can not pass this information just using a redirect parameter because that can be changed by the client user agent. When you redirect to the GenerateAuthorizationCode redirect proxy, do so by appending a random session ID in the URL. That id can be used by the GenerateAuthorizationCode proxy to look up the login status from the session store. Then you can either send back a redirect with error or a proper oauth code based on if the login was successful. An easy implementation of the session store can be done using a distributed caching resource in the apigee gateway. Login app can put/get the session using an internal API. While the proxy can use policies to retrieve the session information.
How can I redirect to non secure URL from the successful authentication of Box API?
I'm trying to redirect to my application URL which is non secured, but it is showing the error insecure_redirect_uri.
How can I overcome this problem?
Box OAuth 2.0 requires an SSL encrypted redirection unless you are redirecting to localhost. We do this because credentials, and secret info like auth tokens shouldn't EVER be transmitted over the internet in the clear (i.e. must be encrypted).
We'll send it to you in the clear to localhost, because we're assuming that you're just doing some proof-of-concept hacking-an-example-together kind of work. We won't let you publish your application with that non SSL callback.
So you can just go into your app settings and set http://localhost:4000 and you'll be fine for your quick hello-world type program.
Given is an application behind a Nginx configured as reverse proxy. The application requires user login via a web form and HTTP POST. Is there a possibility to provide the credentials of a generic technical user to Nginx and let it automatically do a login, so that users don't have to login explicitly anymore?
It might be tough without some kind of module :) but If it is an internal application you might tell nginx to to add certain headers to every request and authenticate by them. But if it is a production app I wouldn't go this path :)