I have been struggling with CouchDB Authentication. My web application is running at https://aaa.com and my CouchDB is at https://bbb.com:6984 so I am accessing CouchDB using JS fetch. When I POST a _session login I do get a set-Cookie header on the response, and most browsers like Chrome comply and add the cookie to the bbb.com website. All except Safari.
I understand this is to avoid 3rd party tracking etc. My question is; what is the "typical" or "recommended" deployment according to CouchDB developers? I would have thought this is a very typical scenario where App server speaks with an API or DB server somewhere else.
Now If I am forced to call everything from the same server, what are the minimum requirements for App vs DB server? Which should work in Safari?
App Server CouchDB
1) BBB.com:5000 BBB.com:6984
2) xxx.BBB.com BBB.com:6984
3) xxx.BBB.com yyy.BBB.com
4) BBB.com BBB.com:6984
Thanks
Related
For the first time, we are developing a new project that needs to support the browser (a website) and a mobile app built on react-native.
We have plenty of experience developing for the web, but little to no experience in the mobile app world.
We are now defining our API and trying to make it work for both platforms - This will be a basic JSON API, running on Flask. The API will have some public endpoints, and some protected ones as well (that require auth). We want a cross platform auth solution.
Typically, for the web, we have always relied on cookie based sessions (encrypted) that frameworks like Flask provide. We have been successfully using these in various scenarios: loading HTML templates directly from the web framework, or even when the frontend application runs on React (same domain + HttpOnly + secure cookies).
The introduction of react-native could potentially bring some new challenges, and some of our developers worry about not being able to continue to use our typical session based cookies - They are advocating to using something like JWT for authorization, for both the browser and app (and yes, I know that we can't compare sessions to token based auth).
I'm not a big fan of token based authorization (for a number of reasons, could entertain that conversation if anyone wants to waste some time...), and I can't seem to understand why we shouldn't stick to our normal encrypted "Cookie" value.
Here is how I imagine this could work, based on using the Flask cookie session:
A user hits /api/login with some credentials
The endpoint will validate the user and return back whatever response + the Set-Cookie header with a value of session=<encrypted string>
Any further requests from the browser/app would send back the cookie value again.
Essentially, nothing would change for typical browser implementations, this is how browsers work by default.
The react-native documentation mentions a few issues with cookie based authentication: https://reactnative.dev/docs/network#known-issues-with-fetch-and-cookie-based-authentication
From what I can gather (my knowledge is extremely limited on this subject), react-native might not always respect the Set-Cookie header. Which is OK - we would just have to make sure to send back the expected header with any further requests.
This, in theory, would fulfil our requirements.
I'm looking for feedback on my "solution", am I missing anything? Did I get HTTP completely wrong?
React Native actually provides networking similar to that of websites developed with basic JavaScript, which also supports cookie based authentication, however there are some serious caveats as mentioned in here
The following options are currently not working with fetch
redirect:manual
credentials:omit
Having same name headers on Android will result in only the latest one being present. A temporary solution can be found here:
https://github.com/facebook/react-native/issues/18837#issuecomment-398779994.
Cookie based authentication is currently unstable. You can view some of the issues raised here:
https://github.com/facebook/react-native/issues/23185
As a minimum on iOS, when redirected through a 302, if a Set-Cookie header is present, the cookie is not set properly. Since the redirect
cannot be handled manually this might cause a scenario where infinite
requests occur if the redirect is the result of an expired session.
Therefore, I would advise against using it as it is unstable and might give you a hard time dealing with it
I also suggest looking into frameworks that handle authentication for you, such as auth0
Hope you find this helpful :)
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'm using adal.js on my react app (using react-adal wrapper). I configured my app to work with my ADFS 2016 server (on premise), and the authentication process works fine, but after the ADFS SSO cookie expired, when the client sends the renew token request (in an hidden iframe), the browser shows in the console the following error: refuse to display 'https://myadfs/adfs/ls/SAMLRequest=...' in a new frame because it set 'X-frame-options' to deny.
In order to reauthenticate, the user needs to refresh the page (F5).
Is there any solution / workaround to this problem?
ADFS <= 2016 does not allow iFrame based logins for any interactive authentication for security reasons. This would have worked if the user did not need to perform an interactive sign-in (either SSO cookie or WIA).
The right pattern (since you are on 2016) is to use OIDC flows to log into the application and use the refresh token to get new access tokens.
Even here you need to handle the refresh token expired case where you will need to store your app context locally (cookie or local cache) and enable a full redirect to ADFS.
ADFS 2019 now has the option where an admin can configure options for which host(s) they allow iFrames by controlling the headers.
Thanks //Sam (Twitter: #MrADFS)
Like I explained in this similar question, the commandlet "Set-AdfsResponseHeaders" is also supported on ADFS 2016 since a recent MS update (about May 2019) :
Set-AdfsResponseHeaders -RemoveHeaders "X-Frame-Options"
Howeber, I agree with SamuelD MSFT on the fact that it's not a good practice any more to use iFrame integration nowadays.
When using the Postman Chrome App with the Interceptor extension it's easy to reuse the browser's cookies in order to log into an app and then call the services within.
Since moving to the Postman standalone app, this process has become somewhat manual. After logging in from the browser, I have to access the JSESSIONID cookie in the developer tools and copy its value over to postman.
When my session expires I need to repeat the process.
I would like to automate this synchronization or at least understand how I could obtain the new authenticated value in postman. It's important to note that none of the authentication mechanisms available in Postman work with my app which is why the manual login in the browser is necessary.
You can get JSESSIONID cookie in Postman Standalone in similar way your browser do it - by send proper requests (probably POST "login" request with user credentials) to server
I have foursquare app that gets authorization from Foursquare. It used to work but after the server upgrade it stopped working as timeout after 30 seconds.
We were using Apache 2.2.6 and PHP 5.2.12 and upgraded it to Apache 2.2.22 & PHP 5.3.17. We updated php codes according to 5.3.17 which are mostly db stuff. Anyhow our Foursquare server side app isn’t not working since. We tried it on other old server with old setup, then it works.
Specifically, access token is not returned on the request for authorization on our app when a user try to use it.
We are using this format below for making the request.
https://foursquare.com/oauth2/access_token
?client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET
&grant_type=authorization_code
&redirect_uri=YOUR_REGISTERED_REDIRECT_URI
&code=CODE
All of values are filled accordingly.
Any hint or clue would be helpful!
You can try requesting the URL from your browser, and seeing the response generated. This should give you more information about the error occurring.
In your browser, you can imitate a user and follow the flow that they would use to authorize your app. Then, you can take the code parameter from the url, and visit the access_token link in your browser to see the response.