Basic Authentication in front of CKAN - too many redirects - basic-authentication

I'm currently setting up a ckan and it was asked that before anyone could access the website, basic authentication was done. After that the user can check out the CKAN without a problem. However my problem resides in the fact that the basic authentication, before anything of CKAN is shown, somehow interferes with CKAN's log-in system. If I, after I entered my BA credentials, want to log in it returns me a "too many redirects". Ofcourse when I don't include basic authentication in my virtualhost, the log-in of ckan works without a problem.
So my question is two-sided, is there a way to let CKAN know that the basic authentication used isn't something he should be using and apparently see as a CKAN user.
Or is there a module in CKAN that allows for Basic Authentication to be asked before anything is shown on the website at all.
Thanks in advance!

Solved!
Found my solution by asking it the ckan mailing list. Altering your apache.wsgi running in your ckan should do the trick. Take a look at this file and add line 13 14 15 17 to your apache.wsgi file and you should be fine. At least I stopped getting endless redirects and was able to log-in after I filled in my Basic Authentication. This however implies that when you use the CKAN API you'll need to use X-CKAN-API-Key header or specify another header in the config file.

Related

Drupal 8 Redirects to external URLs are not allowed by default

I am setting up a website with Drupal, the website is deployed on the live server through bitbucket pipelines. Normally when I browse to myurl.com/user it redirects me to myurl.com/user/login however now I get this error:
Redirects to external URLs are not allowed by default, use \Drupal\Core\Routing\TrustedRedirectResponse for it.
I have already set-up the "trusted_host_paterns" however this doesn't seem to fix the problem.
trusted host patterns:
$settings['trusted_host_patterns'] = array(
'^myurl\.com$',
);
Just in case somebody else comes here: It is also possible, that you have migrated a multi language site to a different server / localhost, and in your database are still the old redirect domains, that will now no longer work.
To fix this, you need to manually change the following value in the database. Go to dr_config and search for language.negotiation
In the cryptic blob, search have a look for something like
{s:6:"source";s:6:"domain";
and change it to
{s:6:"source";s:6:"path_prefix";
afterwards empty all cache_* tables (to force a reprocessing of the configuration) and there is a good chance it might work then.
The pattern seems OK to me. However there is what I'd check:
Confirm using your browser that the redirect to /user/login happens to exactly myurl.com domain. Not www.myurl.com for example.
Try clearing cache as well.
Then looking through this post on DO
And then this one. It's a D8 issue not fixed yet.
I remember having a similar issue on one of my websites during development on a local environment and the issue was really in the pattern.
In the case you have this because of a multilingual site not finding the domains on localhost, put in settings.php:
$config['language.negotiation']['url']['domains']['en'] = 'my-en-url.localhost';
$config['language.negotiation']['url']['domains']['de'] = 'my-de-url.localhost';
$config['language.negotiation']['url']['domains']['es'] = 'my-es-url.localhost';
$config['language.negotiation']['url']['domains']['fr'] = 'my-fr-url.localhost';

How to restrict external access to a specific sub-URL IIS7

I've currently got a reasonably large site up that i've been asked to make changes to.
Currently To login to this site you need to go to:
www.example.com/folder/loginpage.html
This site is only accessible internally at this time and it is unlikely to ever be accessible externally.
We would like to, however, be able to direct external users to a sub-directory on the site (a 'survey' form) which is located in
www.example.com/folder/subfolder/survey.html
This survey writes its results back to the main application and i believe they are integrated tightly.
We initially tried the idea of using an additional IIS7 box as a reverse proxy however it is quite confusing to me, i'm not very familiar with IIS/ARR and the other features required (i'm mostly familiar with networking). I did try and follow a number of tutorials but didn't get very far. I'd like to avoid it if possible.
How can I, using IIS7 (this site is in ASP.NET) restrict external users from accessing anything other than the survey pages (there are a few included files necessary as well)?
Is it possible to make www.example.com/folder/subfolder/survey.html a 'website' in-itself so that i can publish a URL like survey.example.com externally?
I've come across other examples where access is restricted from specific pages but the root of the site is still accessible
ie
www.eg.com/ is allowed but www.eg.com/admin.aspx is denied. I'd like to the the reverse in effect, and if possible, hide the 'true' url.
Hope someone can help! If using a reverse proxy is possible i'm happy to do it but i'd need detailed instructions.
Thanks for reading,
Much appreciated!
Edit: Sorry all, I'm new to stackoverflow, indeed I've just realised that there are several other sub-communities. Is it more appropriate to ask this in a different community? If so, which one?
Thanks!

Pass through Authentication - IIS and dotNet

Sorry to repeat a question that I have seen posted many times before. But they don't seem to answer my circumstances. Or the articles are for previous versions of IIS and IE
I have trying to create a landing page where a user is redirected to an Intranet. I would like users who are part of the domain to be passed straight through to our Intranet with their Windows username (Single sign on). However I would also like the users who do not have a user name to be passed to a login page.
The problems seems to be when Enabling Anonyomous Access on IIS. You can allow access through to the IIS but can not detect the username and vice versa.
I have setup a solution which does something similar to this. However when a user who is not part of the domain accesses the site then they have to click cancel to the dialogue box (Windows login). They are then redirected to the 402 page which is a login page
Does anyone know how to stop this dialogue box being displayed? If I can get rid of the dialogue box then this would solve my problem.
I have looked a loads of solutions which none of them have the desired effect:
http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx
https://community.altiusconsulting.com/blogs/konstantinshapkin/archive/2009/09/22/asp-net-mixed-authentication.aspx
(These two are the most suited match for my problem - but don't see to provide the single page and filter the user to the correct place)
Any help would be greatly Appreciated. Let me know as well if I am asking for the impossible (I have been looking for an answer for days now...) I seem to be hacking the iis server to do something it doesn't want to do...
I have also tried windows and forms authentication bother together which doesn't seem to work on both IIS 6.0 and 7.0.
I don't believe there is a solution to your problem however I know for certain the you cannot (and should not) override the default browser behaviour you mention here:
Does anyone know how to stop this dialogue box being displayed? If I can get rid of the dialogue box then this would solve my problem.

IE Security Warning with widgets

I'm creating an ASP.NET application which uses Facebook Connect and fbml tags. It also uses the LinkedIn widget. When I run this app in any browser, there are no warnings and everything works. However, in IE, a message like this comes up:
Security Warning:
The current webpage is trying to open a site in your Trusted sites list. Do you want to allow this?
Current site:http://www.facebook.com
Trusted site:http://localhost
(same for LinkedIn.com). I know how to fix this from a client perspective and to stop the security warning showing up. However, is it possible to ensure this message doesn't come up as it could be off putting for users who don't know how to suppress this warning? I haven't tried uploading it to my webhost, so not sure if this message will appear for everyone in production. However, I always get it on my local machine.
(None of my pages use SSL, so I don't think that's the issue. I tried using FB's HTTPS urls but that didn't make a difference).
Thanks
I have come across the IE message many times. Whilst this might not be the case here I always check in Firebug to see if any requests are going to Https (using Net tab). If may be the case that something you are referencing is itself making a call to something else.
Often you get that message if you are serving an https page and then going to fetch an image over http.
Might not help but is the first thing I do in this situation.

"The Resource Cannot Be Found: /Login.aspx" on new v5.20 Install

Please see my DNN Forum Post for more details.
I've never had any issues with DotNetNuke installations. But with the new v5.20 (or v5.02, whichever it really is), everything runs perfectly fine through installation. I then get to the main default portal homepage. But as soon as I click any of the links available to continue (Home, Register or Login) I get 404 errors every time with a reference back to the applicable aspx page (Home.aspx, Register.aspx or Login.aspx.).
Windows 7, IIS7, SQL Server 2008. All permissions are setup properly on the directory and in IIS. I would think this is an IIS7 configuration issue, but I've tweaked everything in there a half-dozen times. No one at DNN is returning answers on my forum post anymore either after one guy tried.
Help!
This is something to do with the Friendly URL stuff. I found this blog post which talks about the Friendly URL Provider architecture. This made me try changing the urlFormat attribute for the DNNFriendlyUrl provider from "humanfriendly" to "searchfriendly", which made the URLs the way they used to be. I'm not sure exactly where things are going wrong and don't really have time to dig into it at the moment, but hopefully this will be helpful to get you moving again too.
With the release of DNN5 (up until 5.02.01 as of the time of writing), the friendly URL provider won't work when DotNetNuke is not on default port 80. There are different solutions floating around, but the simplest is just to replace the DNN friendly URL provider with the free one from iFinity. The installation is really simple and included in the download. Or see the following blog post:
http://www.sailer.com.au/dotnetnuke/dnn5-friendlyurl-port
Okay have you tried the 'old style' of login - domain.com/default.aspx?ctl=login
If that still doesnt work then i have to say that most likely something has happened to IIS - if so then you might just see if you can install the package you have on a different box or have a friend try a different box
I have done 2 upgrades with 5.2 and a few test installs with the Starter Kit Package and Install packages and have never seen this problem - not to say that it doesnt exist.
My next trial would be to go and redownload the install package from CodePlex and start from scratch to see if you can make the same thing happen again.
OKayone thing I dont think that has been mentioned in reading through everything is double check IIS.
My first guess without looking on your server would be to check if something happened to the 'check file exists' setting - i know this is changed in IIS7 so I cant point to the exact place to check this.
Here is a link to the IIS7 forums on it - http://forums.iis.net/t/1092696.aspx
http://forums.asp.net/t/1191083.aspx
either one might help - google also has a lot on this
Tell me how this goes in checking up on it and we can move forward from there!
you probably need to reg_iis on the version(s) of asp.net that your IIS is going to support.
http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
If the right version is not set up then you will get the 404 error
So placing it under port 80 works, right?
Is there a good reason not putting it under that port?

Resources