In case you don't know: Basic Auth and Shopware doesn't play well together (read not at all)
So, how do you close down Shopware testing instances? Only allowing certain IPs would be great, but is not suitable all the time, so happy for every idea you have!
IP whitelisting
You can enable the maintenance mode for a sales channel and then whitelist IPs to allow access to the storefront.
Workaround for basic auth
It is possible to secure the storefront with basic auth but for the administration you'll have to exclude the api paths, which shouldn't be a problem as they require authentication anyways.
Apache:
AuthType Basic
AuthName 'Authentication required'
AuthUserFile /www/htdocs/shopware/.htpasswd
# Allow access to excluded path
SetEnvIf Request_URI /api noauth=1
Require env noauth
Require env REDIRECT_noauth
Require valid-user
Nginx:
server {
location ~ .php$ {
set $auth “Restricted”;
if (request\_uri ~ /api/.\*){
set $auth “off”;
}
auth_basic $auth;
auth_basic_user_file /www/htdocs/shopware/.htpasswd;
}
}
Worth mentioning, you can also setup Authelia, which adds a login screen in front of your installation and will set a cookie for authentication.
I think it's mostly used in Dockerized environments.
Related
How would I go about creating a link that contains confidential information specific to the user and when clicked, it would open up a tab that requires authorization in order to access the information.
I've been given advice to use Apache and Drupal but I'm not sure how to start things. Any form of advice would be GREATLY appreciated.
You can use Shield module of Drupal for your purpose.
OR
You should be able to do this using the combination of mod_env and the Satisfy any directive. You can use SetEnvIf to check against the Request_URI, even if it's not a physical path. You can then check if the variable is set in an Allow statement. So either you need to log in with password, or the allows you in without password:
//Do the regex check against the URI here, if match, set the "require_auth" var
SetEnvIf Request_URI ^/your/url require_auth=true
// Auth stuff
AuthUserFile /var/www/htpasswd
AuthName "Password Protected"
AuthType Basic
//Setup a deny/allow
Order Deny,Allow
//Deny from everyone
Deny from all
//except if either of these are satisfied
Satisfy any
1. a valid authenticated user
Require valid-user
or 2. the "require_auth" var is NOT set
Allow from env=!require_auth
I have just setup nexus 2.8.1 and a reverse proxy via the following directives in an Apache 2.4 configuration.
<Location /nexus>
RequestHeader unset Authorization
ProxyPreserveHost On
ProxyPass http://nexushost.server:8082/nexus
ProxyPassReverse http://nexushost.server:8082/nexus
RequestHeader set X-Forwarded-Proto "https"
</Location>
However, whenever I try to login it always fails with a invalid username/password or access to ui not enabled.
If I try the same access by going directly to the http://nexushost.server:8080/nexus page then I don't have any issues logging in with the same credentials.
Has anyone else experienced a similar issue.
You have to map cookies to be passed through as well as a few other things. Check out the documentation in the Nexus book.
http://books.sonatype.com/nexus-book/reference/install-sect-proxy.html
Specifically the cookies are required for the UI to work in a browser.
I believe your problem comes from this directive:
RequestHeader unset Authorization
I guess you're doing that because you're using Basic auth in your Apache and you don't want the Authorization header to drift unto Nexus. Unfortunately Nexus uses the same header to perform authentication (you can verify this by opening the network analyzer of your browser).
I came up with the following strategies:
You perform basic auth in Apache and disable auth in Nexus, by giving anonymous all the rights for example. For obvious security reasons, you must make sure that Nexus is bound to 127.0.0.1 and not 0.0.0.0.
You disable basic auth in Apache (plus of course removing the above directive) and let Nexus perform the authentication.
You map your Apache user/passwords to those of Nexus. You'll need to remove the above directive to let the Authorization header propagate to Nexus. This gives you the advantage of not showing Nexus at all for unauthenticated users, while retaining the right management of Nexus. The only drawback is that you need to manage passwords in 2 places.
Same as 3 but to workaround the password management overhead, you set in nexus the same password for all your users (e.g 'nexus_password') then you make Apache rewrite the authorization header with this password. Here is an example of Apache configuration that does it:
RewriteEngine On
RewriteMap base64map prg:/usr/bin/b64
<Location />
RewriteCond %{REMOTE_USER} (.*)
RewriteRule .* - [E=R_U:${base64map:%1:nexus_password}]
RequestHeader set Authorization "Basic %{R_U}e"
</Location>
With /usr/bin/b64 wrapping around base64:
#!/bin/bash
# MANAGED BY PUPPET
# This is an apache RewriteMap interface for base64 : apache runs this program only once at startup
# See http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewritemap
while read line; do
echo -n $line | /usr/bin/base64
done;
Same as 1, make sure Nexus is bound to localhost.
OS: Linux OpenSUSE
Version control - Mercurial
Apache2
I run http ://my.os.name/ it gives me a page - thus apache is running.
I run http ://my.os.name:/hg - It shows me Mercurial page, thus mercurial is
showing up on http Internet Explorer page.
I'm able to create repositories/or do normal work in Mercurial.
What I need.
1. When I open the above Hg link
then, instead of showing me the Mercurial(Hg) repository page home page, it should first check whether I belong to my company or not i.e. it should authenticate using Windows Active Directory or LDAP server.
If I'm making any changes to a file or create a directory / repository in Hg, then it should make sure / authenticate/verify whether I have valid access to do that operation or not.
HOW can I do this, I need step by step help as I'm new in Apache/Mercurial authentication setup.
I have almost read all the Online help in setting this up and so far I'm able to get to a point whether when I open Hg link, I get a popup for username/password prompt, but its not taking it / not working.
I also dont want to create .htpasswd/ .htaccess or digest files. What I'm wondering is that if in Windows Active Directory, if I have a Security group created for ex: Company/Project1_readers, Company/Project1_Contributors, Company/Project1_Repository1_Readers, Company/Project1_Repository2_Contributors... and in those AD security group ids, if I have all the developers added, then using these groups in AD, I want to grant access to developers instead of adding those users in .hg/hgrc file.
(This is what usually we do in TFS (Team foundation Server) to grant/revoke access) instead of messing with files (adding/removing users) in every repository etc.
How can I do the above?
Kindly advise if the best way is only creating .htpasswd/.htaccess/.htdigest etc files...if I'm wrong in achieving the above scenario.
My httpd.conf file Includes another .conf file (which contains)
=========================================
<Directory /srv/www/hg>
Order deny,allow
Deny from All
AuthType Basic
# #AuthName "Apache Web Site: Login with your AD(Active Directory) credentials"
AuthName "Mercurial Repositories"
#
#
# AuthBasicProvider ldap
# AuthzLDAPAuthoritative off
# #AuthLDAPURL ldap://10.211.16.1:389/OU=TSH,DC=tsh,DC=Mason,DC=com?sAMAccountName
# AuthLDAPURL "ldap://10.211.16.1:389/?samAccountName?sub?(objectClass=user)"
## #ldap://ldap.your-domain.com:389/o=stooges?uid?sub
# AuthLDAPBindDN "cn=xyzserver,OU=Services,OU=Users,OU=Infrastructure,OU=DEN,OU=KSH,DC=Psh,DC=Mason,DC=com"
# #"cn=StoogeAdmin,o=stooges"
# AuthLDAPBindPassword secret1
require valid-user
# require ldap-user
Satisfy any
</Directory>
When I'm using the abvoe LDAP URL in Jenkins, Jenkins is successfully authenticating a user while logging in, then why the same is not working when it's in this server's .conf file. Note, in apache2, the above doesn't have to be in httpd.conf file. Include concept is letting me include the file.conf and file.conf contains the above code. This is as per Apache2 directions as mentioned in httpd.conf file.
Rest of the mercurial files hgwebdir.cgi, hgweb.cgi, hgweb.config are all good (as per online blogs I have read).
I have all the required modules loaded (as they are visible in /etc/apache2/sysconfig.d/loadmodule.conf file (modules which are required for LDAP auth i.e. mod_ldap, mod_authz_ldap etc etc related to ldap and apache).
OK, Prompt part which was not taking my Windows Ldap credentials is now working.
What did I put wrong.
- See line: for AuthLDAPURL and AuthLDAPBindPassword, those were the culprits in my post shown above.
- Cause was, I was new to Windows AD/LDAP concept, so couldn't get a hold of anyone from Systems team in my company. So tried my own hands. The first line for AuthLDAPURL, I got from the GLOBAL configuration file (config.xml) of one of our Jenkins instance.
Jenkins GUI for showing config doesn't show passwords (as they are masked) so there you'll see Manager's DN password as "* * * * * *".
So, I thought I should open the config.xml file of Jenkins instance and got the password "secret1" from there. Actually "secret1" is just an example, in reality it was some crazy value over there like "VVX12##!5GH".
So basically I used that earlier which didn't work as for LDAP authentication to work correctly, you have to talk to someone in SYSTEMS team or the person WHO actually did the setup in Jenkins instance for LDAP authentication there.
Finally I got the password, and it worked.
Resolution: See below what I changed.
One important thing to notice is that, in Jenkins, AUTHURL for LDAP was:
AuthLDAPURL ldap://10.211.16.1:389/OU=TSH,DC=tsh,DC=Mason,DC=com?sAMAccountName
but,
from a Unix/Linux/in my case, SUSE machine, we have to change this line a little bit to
AuthLDAPURL ldap://10.211.16.1:389/OU=TSH,DC=tsh,DC=Mason,DC=com?sAMAccountName?sub
For more on this (Apache2.2 on connecting to Windows AD(Active Directory) authentication):
PS: http://www.yolinux.com/TUTORIALS/LinuxTutorialApacheAddingLoginSiteProtection.html
and then
- I put the correct password for cn=xyzserver (Manager DN user id) in the file and all was good then.
Snapshot of apache config file or the file which you have created separately and included in your httpd.file or through /etc/sysconfig/apache2 filer (variable APACHE_INCLUDE...) now looks like:
<Directory /srv/www/htdocs/hg>
Order deny,allow
Deny from All
AuthType Basic
AuthName "LDAP Access - Mercurial"
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthLDAPURL ldap://10.211.16.1:389/OU=TSH,DC=tsh,DC=Mason,DC=com?sAMAccountName?sub
#AuthLDAPURL "ldap://10.211.16.1:389/OU=TSH,DC=Mason,DC=com?sAMAccountName?sub?(objectClass=*)"
AuthLDAPBindDN "cn=xyzserver,OU=Services,OU=Users,OU=Infrastructure,OU=DEN,OU=KSH,DC=Psh,DC=Mason,DC=com"
AuthLDAPBindPassword CorrectPassword!
# require ldap-user c149807
# AuthUserFile "/dev/null"
require valid-user
Satisfy any
</Directory>
I'll work on getting the user access part now on the actual repository as Auth part is done from IE(Internet Explorer) to Hg(Mercurial) from Linux/Unix/OpenSUSE machine.
if prompted multiple times for user credentials in mercurial. Setup Mercurial_Keyring and then
this question comes which nobody explained in an easy way.
??? how to make the [auth] xx.prefix = servername/hg_or_something work for all repositories under servername/hg location either if I use servername, servername's IP or servername's FQDN ?
ANSWER: Arun • 2 minutes ago
−
OK, I put this in ~/.hgrc (Linux/Unix -home directory's .hgrc hidden file) or Windows users %UserProfile%/mercurial.ini or %HOME%/mercurial.ini file.
[auth]
default1.schemes = http https
default1.prefix = hg_merc_server/hg
default1.username = c123456
default2.schemes = http https
default2.prefix = hg_merc_server.company.com/hg
default2.username = c123456
default3.schemes = http https
default3.prefix = 10.211.222.321/hg
default3.username = c123456
Now, I can checkout using either Server/IP/Server's FQDN.
I have a CakePHP Application which I want to protect with a password. The tricky thing is, that all files/locations should be only accessible with a password EXCEPT one specific Address (a function withing a CakePHP-controller)
The Address is like that:
http://example.com/MyApp/MyController/MyFunction?MyParam=MyValue
All other locations should be only accessible with a password
http://example.com/MyApp/MyController/MyOtherFunction
http://example.com/MyApp/MyController/MyOtherFunction
http://example.com/MyApp/MyOtherController/MyOtherFunction
Well, I tried it first in the root .htaccess-File, but the whole rewrite-thing of CakePHP makes it very difficult and in .htaccess-Files are no <LocationMatch> directive allowed. So I tried it with <FilesMatch>, but the real File is always the same: index.php. mod_rewrite rewrites all Addresses to
http://example.com/MyApp/app/webroot/index.php?url=$1
In the next step I tried it in the apache-configuration and put there this section
<LocationMatch ^/MyApp/MyController/MyFunction.*>
AuthType Basic
AuthName "Secure Area"
AuthUserFile /path/to/.htpasswd
Require user MyUser
</LocationMatch>
Well the regex matched, but it was the wrong way. It protects MyFunction but not the rest.
Are you using .htpasswd? You might be better using Cake Auth, then you can do this in the appropriate controller:
function beforeFilter() {
$this->Auth->allow('MyFunction');
}
I have a domain that will be accessed by a small, private group of people. So I want to control access via authentication.
The domain has a collection of applications installed that each have their own sub-domain. Eg: domain.com, app1.domain.com, app2.domain.com, app3.domain.com
I'd love to have a single sign-on solution so they don't have to authenticate themselves for each application. Also, the applications are written in different languages (PHP, Python and Perl) so authenticating users through an Apache module is ideal.
I am new to digest authentication, but it seems like a good solution. I have used htdigest to create my users. I have configured my domain and sub-domains (See below).
If I go to the domain or any of the sub-domains it will prompt for a username and password. If I enter a correct username and password, it will authenticate me and the page will load. However, if I go to another sub-domain, it will ask for me to enter a username and password again. If I enter the same username and password, it will work.
So the password file is OK, and authentication is OK, but the problem seems to lie in the configuration of the AuthDigestDomain.
I have searched all over the net to find an example of using Digest authentication on multiple domains, but I cannot find a specific example that solves my problem.
I am hoping someone here can assist. Do I put the same authentication information in every Directory? Should I be using Directory or Location or Files? Have I missed something all-together?
Thanks in advance!
Below is an example of my Apache config for domain.com:
<Directory /var/www>
AuthType Digest
AuthName "realm"
AuthDigestAlgorithm MD5
AuthDigestDomain / http://domain.com/ http://app1.domain.com/ http://app2.domain.com/ http://app3.domain.com/
AuthDigestNcCheck Off
AuthDigestNonceLifetime 0
AuthDigestQop auth
AuthDigestProvider file
AuthUserFile /etc/apache2/.htpasswd-digest
AuthGroupFile /dev/null
Require valid-user
</Directory>
And here is an example of app1.domain.com:
<Directory /var/lib/app1>
AuthType Digest
AuthName "realm"
AuthDigestAlgorithm MD5
AuthDigestDomain / http://domain.com/ http://app1.domain.com/ http://app2.domain.com/ http://app3.domain.com/
AuthDigestNcCheck Off
AuthDigestNonceLifetime 0
AuthDigestQop auth
AuthDigestProvider file
AuthUserFile /etc/apache2/.htpasswd-digest
AuthGroupFile /dev/null
Require valid-user
</Directory>
To baffle things even further, this works when using IE6, but not Firefox or Chrome. Is it the clients not sending the authentication properly, or is is the server not sending the correct credentials?
I have also been reading up on RFC 2617 and written the authentication headers using PHP to ensure that the request/response challenge is correct. This hasn't helped at all!
Most browsers do not respect the Digest "domain" directive and will not resend credentials for other URIs. As far as I know, Opera is the only browser that honors it.
For Opera, the server(s) must respond with the same "realm" string for each URI in the domain list. In other words, if domain="/test /example", the server needs to send "Test Realm - example.com" in the WWW-Authenticate header for both of those URIs. I assume Opera does this because it stores H(A1) instead of the actual password for security. Read into RFC2617 for more on this.
Here's my cross-browser solution to this problem: http://travisce.com/arest/
I have no experience with something like this myself. But I just took a look at the Apache documentation and found this:
The AuthDigestNonceLifetime directive
controls how long the server nonce is
valid. [...] If seconds is less than 0
then the nonce never expires.
So it seems to me that 0 seconds (the value you are using) is either illegal or really tells Apache to expire the nonce after 0 seconds which would exactly explain the behavior you are geting.
Could a wildcard on the AuthDigestDomain help?
*.domain.com