Follow-up question to this.
I am currently trying to set up a Web Application to display reports on an intranet site, using the intranet login to authenticate users, passing the authorization process to icCube. I'm trying to get it to work with a local install of xampp apache using basic auth and a local install of icCube. My scripts are based on icCube's live demo.
When I start my Web App with an empty Cache & Cookies, the App is unable to load, throwing me a lot of errors similar to these:
WebApp errors
The reason for these errors is the fact that the GET-requests for the resources are answered with code 401, which is a text/html. This means that my WebApp is not authorized to fetch the .css and similar resources from the icCube-server.
Logging into my icCube interface solves the errors, as that authorizes my browser session to get data from my icCube server.
Is there any workaround for this problem? As far as I know, the resource URIs are generated from the ic3root and ic3rootLocal passed to the ic3Start-function on the html-page, which means that I can not just pack all the .css-files into my apache folder and link them.
Is it possible to authorize my WebApp to get these resources based on the same authorization process used to get my report selection (proxy configuration)?
It looks like because Apache does not " secure " the icCube URLs with its Basic Auth. configuration and let non-authenticated requests reaching the icCube server.
Note 1: You can access " public " HTML resources (i.e., with no authentication required). For that you can use the icCube.xml property (see doc. in the file).
Note 2: You can deploy the icCube Web Reporting application with you Web App HTML files in " Apache " and configure the Web Reporting for accessing icCube server elsewhere (worth a different question).
Related
I have an Azure Web App that uses Python & Flask to run various reports. The directory is structured as follows:
https://my-site.azurewebsites.net/
https://my-site.azurewebsites.net/report-1
https://my-site.azurewebsites.net/report-2
I would like the permissions to work as follows:
https://my-site.azurewebsites.net/ - anyone with Microsoft Authentication in my domain can access (this is done)
https://my-site.azurewebsites.net/report-1 - specific people with Microsoft Authentication in my domain can access
https://my-site.azurewebsites.net/report-2 - other specific people with Microsoft Authentication in my domain can access
If someone without access to https://my-site.azurewebsites.net/report-1 tries to access that URL, it should redirect to an error page (/permissions-error or something) with a link to the primary domain.
What is the best way to configure the Authentication/Authorization/Permissions?
So far, I have been able to set up the authentication for the primary domain but can't figure out how to do the configuration for the report pages.
My current setup is like this. The entire project was built using the official docs here - https://identityserver4.readthedocs.io/en/latest/
API Server
Auth Server with local login, google login and github login
Console based c# client
JS based client
MVC based client.
(all of it, as described in the official docs)
Locally, all of them work beautifully. Able to login, access api endpoints, logout, redirect, the whole thing works smooth.
I have deployed all 5 of them to five different azure web apps. They all have the standard xyz.azurewebsites.net domains ready to use. Now, I have run into some problems.
the console C# client is able to talk to the deployed auth server, collect token using a local account on the auth server and make calls to the deployed API server. Based on this, I assume that both the api server and the auth server working hand in hand, as they should.
Problem #1 - the JS client keeps saying
'The login is blocked because of CORS Missing Allow Origin '
Problem #2 - the MVC client loads the auth server, and then the auth server gives me this error.
Sorry, there was an error : unauthorized_client
Request Id: 80005c0f-0000-eb00-b63f-84710c7967bb
Note : I have set the CORS policy on the auth server, both these clients, under client definition as follows. I am not too concerned about keeping the auth server open, so dont mind if any and every domain can call the auth server.
AllowedCorsOrigins = { "*.*" },
Also Note : I have set the URLS in the code before deployment. all loclahost:port number lines have been replaced correctly with the corresponding now published URLs.
So, what am I missing out here?
Update 1
I was able to solve the CORS issue. Have posted a answer here on another question.
Not able to enable CORS for identity server 4 in asp.net core
Update 2
So, now, both the JS client and the MVC client, are giving identical errors.
Sorry, there was an error : unauthorized_client
Request Id: 80005c0f-0000-eb00-b63f-84710c7967bb
Update 3
I have opened an issue which has log details.
https://github.com/IdentityServer/IdentityServer4/issues/4691
I am not sure if this counts as an answer, but posting for my own question, as it might might help others. Also, this is only a guess at this point.
I found out that the redirects were permanently stored in the database I used with EF migrations. That mean, local in memory redirects were being overwritten anyway by the database stored migrations. I believe this is the issue.
I also realized that the console app is working fine for it does not depend on redirect URLs where as the JS and MVC based clients dont work because they do depend on redirect URLs.
At this point, the best thing to do and for you (if you used EF migrations to store your auth server configuration) on database would be start over and switch to in memory only. Alternatively, you can try and update the database to suit your deployment requirements.
Ultimately, I believe, unless it is absolutely necessary, keep the auth server config (like redirects and CORS settings) in memory as they dont take up much value and are rarely changed.
I have been trying to resolve this for some time now. I tried googling for this problem but didn't manage to find anything. All the questions I found were about replaying already recorded HTTPS requests.
So, I need to record HTTPS requests on a site protected with simple authentication (the pop-up window asking for username and password).
And this is where I get stuck. I enter correct login details and confirm it, nothing happens and in a second i get prompted to enter login details again, no error message nothing. When I press ESC I get 401 UNAUTHORIZED error.
Basically the site is acting as if the login details were incorrect when in fact I tried the same login details without Jmeter's proxy and the server accepted it.
What I tried:
1) Logging into this site without JMeter's proxy - works without problem
2) Recording different HTTPS site with JMeter's proxy - I tried my email and that works correctly as well
I should also mention that I am behind a company proxy, but I tried it at home and the result was same.
As for JMeter configuration, I am using everything on default having:
Thread Group
HTTP Cache Manager
HTTP Cookie Manager
HTTP Request Defaults
Recording Controller
HTTP(S) Test Script Recorder
Guessing the Thread Group doesn't really matter since I don't run any tests, only recording.
Additional Details:
Server:IIS
Logging into sharepoint website
EDIT:
Forgot to mention I tried already Blazemeter Extension, but when i try to record the logging session, it just freezes. Website hangs on trying to contact Blazemeter Cloud and Blazemeter plugin freezes, making it imposssible to stop recording and having to restart whole browser.
Also just noticed that when I am already logged in and try to access the site it records it without any issue. So it's only the login which is problematic for some reason.
JMeter removes cookies and authorization headers while recording.
You can use JMeter Chrome Extension as an alternate way of recording your test scenario.
In order to properly replay the recorded script you'll need to add HTTP Authorization Manager to it .
Sharepoint can have different authentication types, i.e.
Basic HTTP Authentication
Windows Integrated Authentication (NTLM)
Kerberos
See Windows Authentication with Apache JMeter guide to learn how to bypass each authentication challenge in your JMeter test.
So I was able to finally resolve this. The issue lied in sharepoint authentication. I was logged in a domain with my personal account, but was trying to access the sharepoint using a different account.
Sharepoint ignored the login details I was prompted to enter and used mw domain credentials instead. So the answer for me was to access the sharepoint website while being logged into domain(windows) with the same account.
We are currently facing a production issue on Websphere 7 with respect to richfaces fileupload component. The problem description is that immediately after the file for upload is browsed and selected using this component, the basic authentication dialogbox appears asking for user credentials.
Following are the frameworks we are using in our project:
JSF 1.2 & Richfaces 3.3.3
Spring Framework 3.x
Spring Webflow 2.1
Spring Security 3.x (only basic authentication using login dialogbox)
The user is authenticated once when he wants to access the application at the beginning using basic authentication. All screens that dont use fileupload component are working fine. But if we use fileupload component, as I mentioned above, the file selection (even from local machine path) triggers the basic authentication dialogbox again. The strange thing is that this behaviour does not occur on our Dev Environment which uses Tomcat 6. On Tomcat, the fileupload is not triggering any user login and upload is working fine.
This problem is occuring only when the app. is deployed on Websphere 7. Can anybody please tell whether Websphere requires any additional configuration for accessing Files through this component ?
We have spent a lot of time investigating this problem without any meaningful results. As this is a production issue for us now, it is very critical and needs to be resolved at the earliest.
So please help in this regard. Thanks in advance.
I don't know the File Upload component, and the answer may well lie in the detail of how that works, but in general WebSphere will challenge if an HTTP request arrives for a protected resource and the request does not contain a valid LTPA cookie. The cookie is normally sent by the browser on each request when authentication has happended once, BUT it will only do so if it believes that the cookie is related to a given domain. So if the main part of your website were served from, say,
htpp://my.own.org.com/mysite
and the file upload were related to a subtly different host
http://my.other/filesite
Then the cookie would not be sent, and a challenge would result.
My approach to diagnosing this would be get some kind of traffic sniffer. See exactly what is flowing and the addresses being used. I'm predicting that you will see the LTPA cookie in the usual case and not in the upload case. Then it's a matter of figuring out "why".
I am getting the error below while getting the Search Crawlers to work:-
The start address sts4://mysites/contentdbid={3d198865-7f27-4633-bd71-902795032d78} cannot be crawled.
*Context: Application 'Search_index_file_on_the_search_server', Catalog 'Search'*
Details:
Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled. (0x80041205)
I have checked all permissions and they appear to be in order.
While investigating this problem I discovered that when I RDP to the SharePoint server and connect to the sites whilst on the server (locally to the server) I get access denied.
The Central Administration works just fine, but all the other Web Applications (intranet & mysites) will not allow me to login. I get prompted to enter username and password (like I do when connecting to CA) but it never accepts the login. These sites work without any problems when accessed from client workstations.
When I check the site log file it is reporting a http 401 Unauthorised error.
Note: The sites are not using Claims Authentication
Any ideas on how to fix this?
Thanks,
Andrew
You're probably having the loopback issue problem. Follow instructions in this KB article: http://support.microsoft.com/kb/896861