I have this in my .htaccess to require a password but allow certain whitelisted IP addresses without authentication.
Order deny,allow
Deny from all
AuthType basic
AuthName "Admins Only"
AuthUserFile /etc/apache/.htpasswd
Require valid-user
#replace xxx with IP allowed
Allow from xxx.xxx.xxx.xxx
Satisfy any
Using Apache 2.2.16 on RedHat.
Two things are happening here:
It still asks the whitelisted addresses for password, and
when I visit the site on my Android device, I can see the website behind the auth popup, then when I cancel it, I can still browse the site.
Has anyone else experienced similar symptoms and have suggestions?
Note: When I remove the Deny, Allow, and Satisfy rules, the auth works as expected.
Turns out the Satisfy any directive was being met in a couple other locations. Particularly in my apache httpd.conf file, and an .htaccess in a subfolder of the DocumentRoot.
If you're having similar issues with satisfy any, check any other possible locations where .htaccess may be called from and comment out any Order deny,allow and Allow from all statements. Using something along the lines of these commands helped me find the problems (in linux via ssh):
cd /www/documentroot && find -name .htaccess
Or
grep -rli 'allow from all' .
(the 2nd command will search through files so it will take more time)
Or find it in your apache configuration files. Note that you shouldn't have to change the apache config if AllowOverride all is set for your vhost.
Related
W/System.err: java.io.FileNotFoundException:http://192.168.0.102/login/register.php
I'm trying to send info in a database, through my android device but.. it showing this error...
try {
URL url = new URL(reg_url);
HttpURLConnection httpURLConnection = (HttpURLConnection)url.openConnection();
httpURLConnection.setRequestMethod("POST");
httpURLConnection.setDoOutput(true);
httpURLConnection.setConnectTimeout(10000);
httpURLConnection.setReadTimeout(100000);
OutputStream os = httpURLConnection.getOutputStream();
BufferedWriter bufferedWriter = new BufferedWriter(new OutputStreamWriter(os,"UTF-8"));
String data = URLEncoder.encode("userid","UTF-8") +"="+ URLEncoder.encode(userid,"UTF-8")+"&"+
URLEncoder.encode("email","UTF-8") +"="+ URLEncoder.encode(user_email,"UTF-8")+"&"+
URLEncoder.encode("password","UTF-8") +"="+ URLEncoder.encode(user_pass,"UTF-8");
bufferedWriter.write(data);
bufferedWriter.flush();
bufferedWriter.close();
os.close();
Exception:
W/System.err: java.io.FileNotFoundException:
http://192.168.0.102/login/register.php
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:250)
at com.loginapp.logintest.background$override.doInBackground(background.java:80)
at com.loginapp.logintest.background$override.access$dispatch(background.java)
at com.loginapp.logintest.background.doInBackground(background.java)
at com.loginapp.logintest.background.doInBackground(background.java:22)
You may receive a FileNotFoundException if you get a bad response from the server (response code != HttpURLConnection.HTTP_OK).
int responseCode = httpURLConnection.getResponseCode();
if (responseCode != HttpURLConnection.HTTP_OK) {
inputStream = httpURLConnection.getErrorStream();
} else {
inputStream = httpURLConnection.getInputStream();
}
You can try accessing http://192.168.0.102/login/register.php in your dekstop web browser to prove that indeed it is available or this is the correct url. You can just comment out the rest of the code in your register.php file and then echo something like
<?php echo 'hello'; ?>
and see if it gets displayed on your browser. It might be that the url for register.php might be wrong.
EDIT
As requested by Ankit, I will provide a short guide of how to make Wamp online. It can help solve the 'Forbidden' issue and I have also posted a Youtube link to help you further. My advice is that do not set a very defined IP like 192.168.{other values}, inside your httpd.conf file as some blogs do. My guide allows any ip address, which makes it possible to allow connections without having to keep changing the .conf files.
OPTION 1: USING THE PUT ONLINE OPTION
1. Using the Put Online Option
There is a new option on the icon tray of wamp server if you left click on it, at the bottom you will see 'Put online'. You can enable it.
Though I use it, I am not sure if it makes Wamp online without prior changes to *httpd.conf* and *httpd-vhost.conf* since I had
already made these changes before I started using it.
What I know is that after changing those files, my Wamp is accessible online even without clicking 'put online' option.
2. Go to '*Control Panel > System and Security > Windows Defender Firewall > Allow an App or feature through Windows Defender firewall*'
Click Allow another app and under Path, browse to the location of httpd.exe (in my case it is '*C:\wamp64\bin\apache\apache2.4.23\bin\http.exe*').
Then select the checkboxes for 'private' and 'public' and then click ok.
3. Restart your Wampserver and click Put online.
4. Please note that if you have skype, then you may need to do this if you icon does not change to green:
i. open skype
ii. then under Tools > Connections, untick the option for "use port 80 and 443 for additional incoming connection".
iii. Save and then close skype
iv. Restart Wampserver.
5. Open you Windows hotspot and share it with your android phone, or vice versa.
6. Open cmd.exe and run the command '*ipconfig*'. Get your IP address
e.g. 192.168.{other values}, mine is usually 192.168.137.1 but it is currently showing 192.168.43.66.
7. In your android phone, type '*http://<that ip address from cmd>*' on your Web browser. It should load the Wampserver page on the browser.
OPTION 2: CHANGING 'HTTPD.CONF' AND 'HTTPD-VHOST.CONF' FILES
Please note that there is no deletion that is done.
For all the lines that I have placed here, you simply need to change from some old value to a new value
e.g require local to require granted, etc, or add a line if it is missing.
1. Open httpd.conf file (found under '*c:\wamp64\bin\apache\apache{apache_version}\conf\httpd.conf*')
2. Save a copy of this original file somewhere else just in case of anything.
3. Locate the following lines and change them to be as below;
..........
#Listen 12.34.56.78:80
Listen 0.0.0.0:80
Listen [::0]:80
..........
# If your host doesn't have a registered DNS name, enter its IP address here.
ServerName localhost:80
..........
# Deny access to the entirety of your server's filesystem. You must
# explicitly permit access to web content directories in other
# <Directory> blocks below.
#
<Directory />
AllowOverride none
Require all granted
</Directory>
..........
DocumentRoot "${INSTALL_DIR}/www"
<Directory "${INSTALL_DIR}/www/">
.......
AllowOverride all
.......
Require all granted
</Directory>
.........
<Files ".ht*">
Require all granted
</Files>
.........
<Directory "${INSTALL_DIR}/cgi-bin">
AllowOverride None
Options None
Require all granted
</Directory>
4. Open httpd-vhost.conf file (found under '*c:\wamp64\bin\apache\apache{apache_version}\conf\extra\httpd-vhost.conf*')
5. Save a copy of this original file somewhere else just in case of anything.
6. Change the code to:
(please note that if you have other extra lines inside that are not here, please DO NOT delete them.
Just add what is missing and change what appears needs to be changed e.g. Require local to require all granted)
# Virtual Hosts
#
<VirtualHost *:80>
ServerName localhost
DocumentRoot c:/wamp64/www
<Directory "c:/wamp64/www/">
Options +Indexes +Includes +FollowSymLinks +MultiViews
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
#
7. Open hosts file (path is '*C:\Windows\System32\drivers\etc\hosts*') and change or add these lines to be these
(you have to launch notepad or any other text editor like notepad++ as administrator so that you can be allowed to change them):
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
8. Go to '*Control Panel > System and Security > Windows Defender Firewall > Allow an App or feature through Windows Defender firewall*'
Click Allow another app and under Path, browse to the location of httpd.exe (in my case it is '*C:\wamp64\bin\apache\apache2.4.23\bin\http.exe*').
Then select the checkboxes for 'private' and 'public' and then click ok.
9. Restart your Wampserver and everything should be okay.
10. Please note that if you have skype, then you will need to:
i. open skype
ii. then under Tools > Connections, untick the option for "use port 80 and 443 for additional incoming connection".
iii. Save and then close skype
iv. Restart Wampserver.
11. Open you Windows hotspot and share it with your android phone, or vice versa.
12. Open cmd.exe and run the command '*ipconfig*'. Get your IP address
e.g. 192.168.{other values}, mine is usually 192.168.137.1 but it is currently showing 192.168.43.66.
13. In your android phone, type 'http://<that ip address from cmd>' on your Web browser. It should load the Wampserver page on the browser.
I know that this is not xml code, but this format just makes it more appealing to read through. Other helpful links that can help you are this, this, this(has helpful images) and How to allow wamp server 3.0 access on another computer | how to solve "Forbidden" access of wamp - Youtube link:
When I try out the example: https://threejs.org/examples/webvr_cubes.html on my Android 7.0 Samsung Galaxy 7 phone using the Chrome browser and the Utopia360 headset, everything works and I can enter VR mode. When I try the exact same thing with exactly the same code, only on my local server, I get "Your browser does not support WebVR. See webvr.info for assistance."
The code is exactly the same and the three.js and WebVR.js files are exactly the same except for where the three.js and WebVR.js files are located in the directory structure (i.e. <script src="js/threejs/three.js" type="text/javascript"></script> instead of <script src="../build/three.js"></script>)
The reason is that the threejs page has an embedded origin token to allow webvr to work without setting the chrome flag enable-webvr, but that only works when the page is served from "threejs.org".
You can see this at the top of the demo pages:
<!-- Origin Trial Token, feature = WebXR Device API (For Chrome M69+), origin = https://threejs.org, expires = 2019-01-07 -->
<meta http-equiv="origin-trial" data-feature="WebXR Device API (For Chrome M69+)" data-expires="2019-01-07" content="ArPzyYNrUDiXsGOh647Ya7MtVUA1nM+WFMnPWu7eoF2nQHOP6mTATIbiv0w+k2kFaPofZG/04ZEQdsACq4IA0wQAAABTeyJvcmlnaW4iOiJodHRwczovL3RocmVlanMub3JnOjQ0MyIsImZlYXR1cmUiOiJXZWJYUkRldmljZU02OSIsImV4cGlyeSI6MTU0Njg4MzAxOH0=">
So you have two choices:
Enable the webvr flag (chrome://flags#enable-webvr) in your phones browser,
Request an origin token that matches the domain of your website here: https://webvr.rocks/chrome_for_android.
Setting the flag worked for me even when page was served via http.
The issue is that you must "serve your WebVR content via HTTPS", according to the Google WebVR status documentation.
Threejs.org is a site that uses HTTPS, but your localhost is almost certainly not delivering the content via a secure connection. That's why you're seeing that misleading warning that "Your browser does not support WebVR", when in fact, it does.
Unfortunately, the available methods to deliver HTTPS via Apache make it sound like the three options to get an SSL certificate for localhosts won't work on Chrome for Android (or are pricey), so using the WebVR polyfill is the best solution for the time being.
It should work even with an untrusted certificate if you proceed. The important thing is that you should have a certificate, of course we are speaking about a development environment 1. However the crucial part: you must use Chrome Canary for Android, see later.
Get Certificate
The easiest way
Use glitch, which is an online full-stack IDE (yep, with node and sqlite, made by the stackoverflow people) which will provide you a trusted subdomain.
Still easy and locally working way.
Creating certificate and corresponding certificate authority (CA)
you should use minica CA tool:
Install minica (You must install and setup a GO and gotools first)
go get github.com/jsha/minica
Run this simple command, you should use you LAN IP instead of localhost, though.
minica --domains localhost
which creates the following files in your working directory
minica-key.pem The private key of your new CA
minica.pem The root certificate of your CA
localhost/cert.pem The certificate of your website
localhost/key.pem The private key to sign of your website certificate.
If you do not know what are these concepts, I recommend this friendly introduction.
Serve your site with your certificate.
You can use the http-server npm package, which is easy to use and can serve certificates
http-server -a 0.0.0.0 -p 8080 -S -C localhost/cert.pem -K localhost/key.pem
then access your site like https://192.168.1.42 or whatever is your LAN IP address.
Install Chrome Canary to your Android
Google play has it.
Setup Chrome Canary flags
Type chrome://flags in your Chrome Canary's URL bar and enable the following flags: #enable-webvr and #enable-gamepad-extensions called WebVR and Gamepad extensions respectively.
Now your are good to go. 2
Notes:
If you plan to deploy your app in production you should acquire a globally trusted certificate from a CA. Let's Encrypt is free and easy automate and backed by the Linux Foundation, and sponsored by many big players.
WebVR on Android Chrome is still unstable and will be changed, so what I wrote will be deprecated soon.
can anyone help me with the following question please:
My Android-App is able to send the data via https when compiling the debug-version, but the release version fails there.
The https certificate is not self-signed and the whitelist plugin is working.
Interesting is, that if the debug version is installed and then the release version is installed without deinstalling the debug-version, everything works out well.
Can anyone help me here? Thank you in advance!
Problem solution:
The SSL-Chain was the problem for me.
1) To check if this might be an issue for your app, too, you may go to:
https://www.digicert.com/help/
Type in your domain (if already available online) and test your SSL-Configuration. If the last point does not say "SSL Certificate is correctly installed" and you bought your certificate from a trustworthy authority, this website already hints you at an issue you might have with the intermediate certificates.
2) Fix issue:
a) The intermediate certificates neccessary came with that SSL.rar-file you've once gotten. With the provider I had chosen, they sent me three .pem files (besides of other files of course) named:
01_COMODO_RSA_Organization_Validation_Secure_Server_CA, 02_COMODO_RSA_Certification_Authority,
03_AddTrust_External_CA_Root
Other authorities might send you something like someName.ca-bundle. That's the same thing, as far as I understood it, and so can skip this a) part.
Concatenate the plain text of these three files, meaning store them in another file - altogether. No additional text changes neccessary. When storing this file, make sure it has the .crt file ending.
b) Upload your chosenName.crt to your server into the same folder your ssl.crt is stored in already.
c) Make this new file known within the system. In your .config file (e.g. default-ssl.conf), the same file you once added the paths to your "ssl".crt and .key in, set "SSLCertificateChainFile" to - example path: "/etc/ssl/ssl.crt/chosenName.crt" - and update the certficates (I used the command update-ca-certificates, but I'm not sure if this was neccessary at all.)
d) Stop and start your webserver. If an error message regarding wrong configuration is displayed, you have probably misstyped the path to the file or it's name and so it cannot be found. If your webserver starts successfully, you're done.
Another check on the link above (I am not allowed to have more than 2 links within this post) should now show you the SSL-Chain (containing now 4 instead of 1 certificate_s) and the above mentioned "SSL successfully installed" message should appear.
Hopefully this will help you!
Further info:
Whether you need this SSL-Chain with 4 certificates or not is probably something that can vary. I looked it up on the comodo-support site because that was the SSL-certificate authority I had to deal with:
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/620/0/which-is-root-which-is-intermediate
With iOS 9, Apple is mandating the use of HTTPS. While this is all good and secure, it forces me to convert all my dev/testing servers to HTTPS. I'm developing for Android and iOS.
Things I've already tried/looked at:
Running iOS 8 - not a long term solution
Self signed servers - requires adding code to both platforms.
Adding root certificate - probably the way to go but expensive in terms of hours spent on this.
I'd like to know how other people are handling this. Ideally, I'd like a solution based on 3 (or not based on 1 and 2), which works well with simulator/emulator and doesn't require jumping through hoops and constant tinkering with root certificate on various devices.
I'll also take a solution for iOS only (e.g. #ifdef) as Android can stay on HTTP.
=====================================================================
Update: 20 Dec
My servers are IP address only. No domain name.
Using plist settings is an option. However, an answer would have to be specific and complete. I would expect to see something like a script that removes plist settings for 'release' builds.
I'm not a security person, but I suspect that leaving whitelisted IP addresses for attackers to use are a bad idea.
You can very easily add domain names for your development servers by using a free DNS provider. I use http://freedns.afraid.org/ and they have some shared domain names where you can add names for IP's you need. I sometimes do this just for internal servers to make it easier to remember where they are!
As for the plist; all you are doing when you whitelist a name like that is telling the phone app that it can talk to that server with HTTP. If you #ifdef DEBUG the ability for your app to talk to those endpoints, then you should have compiled out the ability of the end user to switch to it!
If you are still concerned about it and are looking to have a build step that removes the exemption then PlistBuddy is your friend. You can remove an exemption using the following command line.
/usr/libexec/PlistBuddy -c "Delete :NSAppTransportSecurity:NSExceptionDomains:my.devserver.com" Info.plist
Please put this property in your info.plist if you want to work with HTTP/HTTPS with iOS9.
App Transport Security is enabled by default when using NSURLSession, NSURLConnection in iOS9
You can opt-out of ATS for certain URLs in your Info.plist by using NSExceptionDomains. Within the NSExceptionDomains dictionary you can explicitly define URLs that you need exceptions for with ATS. The exceptions you can use are:
NSIncludesSubdomains
NSExceptionAllowsInsecureHTTPLoads
NSExceptionRequiresForwardSecrecy
NSExceptionMinimumTLSVersion
NSThirdPartyExceptionAllowsInsecureHTTPLoads
NSThirdPartyExceptionMinimumTLSVersion
NSThirdPartyExceptionRequiresForwardSecrecy
Each of these keys allows you to granularly disable ATS or particular ATS options on domains where you are unable to support them.
You can refer the answers to this question here,
How do I load an HTTP URL with App Transport Security enabled in iOS 9?
Transport security has blocked a cleartext HTTP
I updated my Android phone to 4.0.4 and i noticed that a new file nfcee access.xml appeared in the system folder. The idea of the file as far as i understood is the keep a list of signatures, and allow access to the SE and related intends only to the packages that are signed with one of this signatures. So far in this list is of course the signature of the Google Wallet.
Does anybody know how would be the process in future to enter this list? Do you need to ask for permission directly Google?
If you root your phone, you can modify the file. The file contains the list of signatures and package names that are allowed access to the Secure Element (SE). The signatures is a hex-encoded X.509 certificate. To create one, simply include the tag <debug /> in the file and it will print to logcat the hex-encoded signature of applications that are denied SE access, for easy cut-and-paste into this file.
To create an app that can access the SE, you need to add this permission to the manifest:
<uses-permission android:name="android.permission.WRITE_SECURE_SETTINGS" />
To actually access the SE, you need to access a hidden API by importing com.android.nfc_extras:
import com.android.nfc_extras.NfcAdapterExtras;
import com.android.nfc_extras.NfcAdapterExtras.CardEmulationRoute;
import com.android.nfc_extras.NfcExecutionEnvironment;
The easiest way to make this possible is to compile your app in the Android source code tree by placing it in packages/apps and building it from there. You need to add the following line to the Android.mk makefile to get access to the SE API:
LOCAL_JAVA_LIBRARIES := com.android.nfc_extras
The functions in com.android.nfc_extras allow enabling and disabling the SE, sending commands to it and receiving responses from it (comparable to IsoDep.transceive()).
This is interesting indeed. If entering your certificate and package name in this file is all that is needed, you shouldn't need to talk to Google, just get whoever is building the ROM (yourself if custom ROM, or a particular carrier) to include it. The bigger problem though is,
who do you need to talk to to get the CardManager keys. If it is the carrier, you can also get them to pre-install your applet, so you might not need the keys at runtime (unless you want to use a secure channel to your applet).
Update: Here's a summary of SE support in Android and some more info on how to use the embedded one. In short, it does work, but you can only query stuff of course. It runs JavaCard and is GP 2.1.1 compatible, uses 3DES keys for the secure channel.
http://nelenkov.blogspot.com/2012/08/accessing-embedded-secure-element-in.html
http://nelenkov.blogspot.com/2012/08/android-secure-element-execution.html
BTW, here's the currently allowed cert on my GN 4.0.4. A package is not specified, so any app signed with it will get access to the SE:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
a8:cd:17:c9:3d:a5:d9:90
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=Mountain View, O=Google Inc., OU=Android, CN=Google NFC
Validity
Not Before: Mar 24 01:06:53 2011 GMT
Not After : Aug 9 01:06:53 2038 GMT
Subject: C=US, ST=California, L=Mountain View, O=Google Inc., OU=Android, CN=Google NFC
With cavets: If you can get your application on the nfcee_access list you can do the following things:
Enable the UICC (sim card) and enable the embedded secure element (if present)
Open a communication channel to the embedded secure element and exchange data
Receive transaction data from the UICC (sim card) if the UICC wants to send you data (you'll be receiver only).
You can do all this if you root your phone. No need to hack the nfcee_access list to do so, you can just intercept all traffic to the nfc-chip to so so.
What you can't do, even with a rooted phone:
Install applets on the UICC / eSE
Log/Monitor/influence the data-transfer between the embedded secure element/UICC and an external reader, e.g. hack payment systems.
Caveat: You can do almost everthing if, and only if you have the knowledge and the secure access-keys to access the embedded SE. However, if you have these information you wouldn't ask on stack-overflow. :-)
This knowledge is a well kept secret and no one will tell you this secret unless you are a company as big as google, mastercard, visa, american-express and the like.
The answer is simply NO you cannot do anything with the Secure Element. Only SE owner or issuer can allow the access to the SE - i.e. it is Google itself, or might be First Data (http://www.firstdata.com/en_us/products/merchants/mobile-commerce/trusted-service-manager-solution.html), but I think this company is responsible only for the Google Wallet itself, not for the SE management - this might done by SK C&C - I have no idea...
Take it also that way - the precondition for using embedded secure element is that you are offering excellent service and you are Google partner or other phone manufacturer partner (unless you are from Facebook or similar company save your time and do not try that). This is not easy and 99.99% of services cannot be there.
Regarding secure element now you can wait until SWP and SIM cards will become more popular and acceptable solution, since you might be able to get contract with MNO on national level easier or hope in NFC-WI and SD card solution or go with stickers or external accessories like iCarte for iPhone.