I have authentication turned on with Apache Drill 1.10 and can use sqlline and jdbc fine with my configured users. However when I try logging into the web console I can log in but then when I click on the query button I am always redirected to the login page again.
In /conf/drill-override.conf, enable https by adding "drill.exec.http.ssl_enabled: true"
Then connect with https:\:8047
This fixed the problem for me.
Related
I'm debugging a local site.
I'm getting the following message in chrome.
Your connection is not private
Attackers might be trying to steal your information from t.buyamerica.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
This is not new, and normally I just click ADVANCED and Procced ...
but lately it just stuck in a loop and display the error message again.
This is a local site therefore the key-pair is indeed invalid, but is there a way to by-pass this issue without installing a proper https for all my local (vagrant based) servers?
NOTE:
The current by-pass for me is to use the same domain as the original site, so that the local site is www.somesite.com, and the actual site is somesite.com
I solved this issue as follow:
In
System Preference -> Network -> WiFi -> Advanced -> Proxies I saw that Secure Http Proxy (HTTPS) is checked and the value for the proxy is localhost:8888
I unchecked the Secure Http Proxy (HTTPS) and it seems to solve the issue.
NOTE: this is a specific MAC issue that apparently caused by a system upgrade (my current version is 10.10.5 (14F2511) Yosemite, MacBook Air (13-inch, Mid 2012))
I never set a proxy server or run any proxy on localhost:8888
You change your local domain something like http://yourdomain.test.
Don't forget the 'http'. And if you're using .dev, change it to .test
Is there any way to restrict user to stop accessing Web Console or to provide user name & password.
I am using Drill in embedded mode and in window 8.1 operating System.
For Example:-
Drill is running in server, but if someone know my ip address, they can easily access my web console.
So Is there any way to stop accessing my web console. ?
Use a firewall. You can also enable authentication and HTTPS for the Drill web console:
https://drill.apache.org/docs/configuring-user-authentication/
https://drill.apache.org/docs/configuring-web-console-and-rest-api-security/#https-support
I am using "Oracle Database 10g Express Edition" and I am trying to start Database homepage but Google Chrome or Firefox are showing errors. Note: I am not using any proxy.The message shown in Chrome is
Google Chrome's connection attempt to 127.0.0.1 was rejected. The
website may be down, or your network may not be properly configured.
What are the possible solutions?
I had the same problem. I solved it as follows:
When opening Tomcat Application Manager from the shortcut on the Start menu, then it opened the link http://127.0.0.1:8080/manager/html which caused exactly the same error as you report
All I did was remove the :8080 from the URL and it worked
I have a scalable EAP 6.0 web app hosted on Openshift, and I get HTTP 503 error messages whenever I attempt to access the app. How do I fix this.
In my case this was an issue with the HAProxy cartridge, and not my web cartridge. I found this out by attempting to view the HAProxy status page at http://app-domain.rhcloud.com/haproxy-status/ (obviously you'll have to replace app and domain in that URL to match your own Openshift settings). That page was displaying a 503 error.
To fix it, ssh into the HAProxy session using
ssh 1234567890abcdef1234567890abcdef#app-domain.rhcloud.com
You'll get your actual username and hostname from your OpenShift web admin console. Then run
ctl_app restart
This will restart the HAProxy. And for me, that fixed the issue.
Another handy tip I found while debugging this was that you can browse to a specific instance of your web cartridge, bypassing the HAProxy.
In the HAProxy status page, you can see that the web cartridge instance is called gear-1234567890ab-domain. Drop the "gear-" prefix, and then use the remaining hex characters and domain name to form a URL like:
1234567890ab-domain.rhcloud.com
This will take you straight to the specific web cartridge, bypassing any HAProxy issues.
Thanks Phyxx,
Its working for me let elaborate your suggestion so that others can also benefit.
Step 1: cd /var/lib/openshift/your server/haproxy/conf
Step 2: vi haproxy.cfg
step 3: remove " option httpchk GET /"
step 4: save
step 5: ctl_app restart
I have a website that works correctly under IIS 6.0: It authenticates users with windows credentials, and then when talking to the service that hits the DB, it passes the credentials.
In IIS 7.0, the same config settings do not pass the credentials, and the DB gets hit with NT AUTHORITY\ANONYMOUS.
Is there something I'm missing? I've turned ANONYMOUS access off in my IIS 7.0 website, but I can't get the thing to work.
These are the settings that I'm using on both IIS 6.0 and 7.0:
<authentication mode="Windows">
<identity impersonate="true">
What changed from 6.0 to 7.0?
There has been changes between IIS7 and IIS6.0. I found for you one blog post that might actually help you (click here to see it).
Are you running your application in Integrated Mode or in Classic Mode? From what I saw, putting the Impersonate attribute at true should display you a 500 error with the following error message:
Internal Server Error. This is HTTP
Error 500.19: The requested page
cannot be accessed because the related
configuration data for the page is
invalid.
Here is the workaround that is proposed:
Workaround:
1) If your application does not rely
on impersonating the requesting user
in the BeginRequest and
AuthenticateRequest stages (the only
stages where impersonation is not
possible in Integrated mode), ignore
this error by adding the following to
your application’s web.config:
<validation validateIntegratedModeConfiguration="false"
/>
2) If your application does rely on
impersonation in BeginRequest and
AuthenticateRequest, or you are not
sure, move to classic mode.
I hoped that was useful to understand how IIS 7.0 now works.
Is your IIS server set up to be trusted for delegation by the SQLServer? I've run into this before with WebDAV where we've had to have the server running IIS trusted by the file server to authenticate on the file server's behalf.
Interesting... I have the opposite problem - Not being able to get the authentication to be passed from the client browser, through the webserver and onto the database within a large corporate network over firewalls.
I also feel that "end to end user" authentication to the database is a bad idea and a potential security risk. There is nothing to stop the end user from loading up SQL Query and connecting directly to your database, so you'd better have your schema locked down!
#Esteban - Clarified my not very useful in helping you answer.
Typically if you are doing double hop authentication like this, Kerberos is typically involved unless the first authentication is Basic.
I would check the authentication on the IIS 6 servers and make sure that it's the same on IIS 7.
If the IIS 6 box is set to Windows Integrated, then you need to verify the kerberos settings - SPNs, Delegation etc.