I'm using Cloudant as my database, and I've correctly set it up with Cloudflare as a virtual host so instead of having a randomly generated subdomain to my database like this:
f8b3f1f4-b695-4806-someting-fre-bluemix.cloudant.com
I got it in under my custom domain like this:
db.example.com
I've correctly set the SSL certificate and everything is perfectly good.
The problem now is that on the custom domain I can't authenticate (using basic auth) to my DB using the username and the password I use on the randomly generated domain.
on the custom domain (db.example.com), I get this error:
{
"error": "unauthorized",
"reason": "Name or password is incorrect."
}
while on the original domain (f8b3f1f4-b695-4806-someting-fre-bluemix.cloudant.com) the basic auth works just fine.
Cloudant auth needs some way to figure out your username, which it normally does by using the subdomain, which is also your account name and login. Normally, this is added by the load balancer which knows about the subdomain, but you may have to add it manually when using a virtual host (I've never tried). Try adding a header "X-Cloudant-User: f8b3f1f4-b695-4806-someting-fre-bluemix" (or whatever your account is) to your request and see if that changes anything.
Related
I am having some trouble and need some help. I am trying to connect a website to authenticate to Active Directory through LDAP using DNN.ActiveDirectory, but I can only get the "Check Root Domain" portion to pass. Using ldp.exe on the server I am able to connect to the domain controller and query the users on it with the same user name and password I am trying to use with the plugin, and even using my domain admin account makes no difference. I have tried it with every authentication type, changing the root domain (only way that would get the check root domain to pass is the LDAP://domain.local), with/without the domain in front of the username, and with/without the default domain filled out.
I don't have access to the error logs at the moment since I am not at that office yet, so I will get those posted when I can. If I remember correctly the error being logged was an authentication error. LDAP initially wasn't configured on the domain controller so I had to set that up, and admittedly I am not too familiar with it so I followed this guide: https://techcommunity.microsoft.com/t5/sql-server-blog/step-by-step-guide-to-setup-ldaps-on-windows-server/ba-p/385362. I am using the default ports. I stopped before setting up LDAPS, but when I couldn't get that to work I continued through up to the signing the certificate part. I was working on getting the certificate signed when I came across notes that DNN.ActiveDirectory doesn't support LDAPS. My tests with successful connections using ldp.exe were all against port 389. Are there some extra configurations that are needed to get DNN.ActiveDirectory working that weren't covered in that guide, or any common snags I should be aware of?
DNN.ActiveDirectory has not been maintained for a while, and does not support LDAPS afaik - see Checking Root Domain step fails.
My recommendation is to have a look at AD-Pro Authentication.
I've set up an ASP.Net Core project to use Google OAuth signin from this tutorial
I created a client ID & secret using the settings 'Web server' with address 'https://localhost:5001/signin-google' and exposed the secrets to the app as described in the tutorial. I have a basic view which is just the minimum required HTML & JS to show a 'Sign in with Google' button and allow authentication (verified working on localhost).
I created a deployment in a docker container on a Raspberry Pi on the local network. When I navigate to the view with the Google sign in button and click it, I get an error of
Error: invalid_request
Permission denied to generate login hint for target domain.
In the error details it specifies the redirect URL as:
redirect_uri=storagerelay://http/x.x.x.x:8000?id=auth572720
where x.x.x.x is the address of the Pi on our local network
I am assuming this is because the client expects a redirect URL of 'https://localhost..etc' but is getting 'http://x.x.x.x'.
I am unsure how to solve this, it seems like I may need to create another token to enable authentication on my Raspberry Pi (e.g. create another 'web server' OAuth sign in using the re-direct address 'http://x.x.x.x.etc/signin-google' but when I try this I get an error of 'Must be a top private domain'.
All in all this is very frustrating, and I would appreciate any help.
There is no need to create a new credential, just add the new redirect URL to the existing credential.
The redirect URL domain must be a TLD. Choose something like localhost.mydomain.com and then add an entry in your /etc/hosts file to resolve localhost.mydomain.com to x.x.x.x
I'm currently developing with a test store - I'm not sure if that has any relevance.
After successfully creating a webhook (response to being created below), I have been unable to get it to fire.
{
"id": 13300,
"client_id": "d8xgoreoa4qggw30lx7v0locfxoqna7",
"store_hash": "vh2s7g3i",
"scope": "store/order/statusUpdated",
"destination": "https://www.[HIDDEN].com/bigcommerce-api/webhooks/",
"headers": null,
"is_active": true,
"created_at": 1424993422,
"updated_at": 1424993422
}
Questions:
Is it possible to list all active webhooks from within the store management area? EDIT: I am able to request an active list of webhooks through the API, I am curious if it is possible to see these same active hooks within the store management area.
Is it possible to force a webhook to fire? Because updating order status does not seem to be making calls to my destination URL.
To address your questions:
It is not possible to see a list of all active webhooks from within the Control Panel. You can only see that via the API and you can only see webhooks which you created with your API access token and client ID. Other apps installed to the same store who register their own hooks are segregated from yours.
Updating the status of an order is forcing the webhook to fire as the event occurred. There is not a way to trigger the webhook to fire without causing the event tied to the scope of the webhook.
If you are not receiving these webhooks the most likely issues are either the SSL installed at your destination URL is missing Intermediate CAs, or, that your servers are not properly configured for an SNI enabled request.
What to do to test:
Start with the "Troubleshooting" steps seen at the bottom of this page:
https://developer.bigcommerce.com/api/webhooks-getting-started
You can run a test on your domain at the SSL check site mentioned to confirm you have all of your Intermediate CAs and no other obvious errors. Assuming all that checks out the next thing to look at is your server configuration. If you are using a virtual server then you need to make sure that your server is properly configured to accept an SNI protocol message and respond with the proper SSL for your destination URL hostname.
The process of configuring an Apache server to work properly with SNI is as seen here:
https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
This process will differ by server type but generally you need to make sure your vhost configuration is setup properly for your destination URL if you are running a virtual hosted setup. If your server is not setup to use the SNI protocol and is configured incorrectly so your hostname is not in the vhost configuration file (or default SSL config file), then you will not be able to receive webhooks.
If your server is not a virtual server then you just need to confirm that your default SSL configuration file is including your destination URL hostname as part of the default SSL config.
If a request to your destination URL is met with an SSL that does not match your domain in the initial SSL handshake, then the request will not go through.
Let me know if you are still having problems after looking into the above and we will see what else we can test.
I want to configure a custom port for the redirect URL in the Google Developer Console for the class of 'Installed Apps'.
Following the instructions in https://developers.google.com/accounts/docs/OAuth2InstalledApp , it turns out that this should be possible:
redirect_uri=http://localhost:9004&
Going to the Console ("console.developers.google.com"), "Credentials", and "Create New Client Id", I cannot find the field, where to enter a custom port number. Does anyone know how to do this?
Thanks!
In fact, The document you've read has answered you question:
When you create a client ID in the Google Developers Console, two redirect_uris are created for you: urn:ietf:wg:oauth:2.0:oob and http://localhost. The value your application uses determines how the authorization code is returned to your application.
http://localhost signals to the Google Authorization Server that the authorization code should be returned as a query string parameter to the web server on the client. You may specify a port number without changing the Google Developers Console configuration.
I tried this idea and it works.
Give consecutive ports or probable ports in credentials as
**Redirect URIs**
http://localhost:55738/YoutubeVideoList.aspx
http://localhost:8080/YoutubeVideoList.aspx
http://localhost:8081/YoutubeVideoList.aspx
http://localhost:8082/YoutubeVideoList.aspx
http://localhost:8083/YoutubeVideoList.aspx
http://localhost:8084/YoutubeVideoList.aspx
and don't forget to give correct redirectURI with port(anyone above) while calling the authentication process.
We have our own web server hosting our website that is open to the public outside of our network.
I have a request to make our "Internal Postings" link on our Careers page to authenticate the user against our network's Active Directory list.
I currently have it setup so the link hits a page inside the directory structure of the website, and this page's folder is set to "Integrated Windows Authentication". Anonymous access is turned off for this page. If the user is authenticated (ie: logged into our network or supplies proper credentials) it passes them on to an external careers website which hosts our job postings. If they fail to authenticate, it displays a custom 401 error page.
This works fine, but there is a problem with it. Using IE, people cannot just enter their username. They (of course) are required to enter the domain name as well. Unfortunately the default 'domain' is set to the URL of our website (www.xyz.com/username). I would like it to automatically choose the name of our internal domain (aaa/username) but am unsure of how to do this.
Another option would be to use LDAP and a little ASP scripting to authenticate the user. I have this code already, but am unsure of the security consequences of doing so. Basically, the page will be setup for anonymous authentication, and if the user isn't logged into our network, they will be prompted for a username/password using standard textboxes. This is then passed to an ASP script that does an LDAP lookup against our Active Directory. Is there any security issues with this method?
Which method would you choose to do?
Thanks.
EDIT: It seems I cannot authenticate to ActiveD via LDAP using a username/password combo. So forget about that option.
My question now is, how can I change the default 'domain' that IWA uses? Is that at all possible? IE seems to default to 'www.xyz.com\username' (my website) rather than 'aaa\username' (my domain name). Of course, www.xyz.com\username fails because that is not where our ActiveD resides... Is this possible? I want to make it as simple as possible for our employees.
You cannot authenticate an user with a script that looks up the user in LDAP. You need to know that the user is who it claims it is, and the only way to do that is to let NTLM/Kerberos authenticate the user (ie. establish proof that the user knows a secret stored in the AD, the password).
The URL of the web site to the set of sites considered be in the local intranet zone for IE browsers running on the internal network. By default sites consider to local intranet will be sent the current logged on users credentials when challanged with NTLM/Kerberos. Hence your internal users shouldn't even see a network logon box.
I hate to dredge up an old thread, but the answers are a bit misleading, if I understand the question. The thread Remus refers to is about authenticating via LDAP with a username only. As he points out, that isn't possible. But it looks like what Kolten has in mind is authenticating via LDAP with a username and password both. That's a standard practice called binding.