we've fought with following problem using spring security 1.2.1, grails 1.3.7 and tomcat 7.0.22. on our dev machines we had no problems during login in our app. i think the grails tomcat plugin uses a 6.x verion of tomcat. we defined following test cace for the login process:
delete all cookies
login
as you can see a very simple test case :-). the result of the test looks as follows: the user was successfully authenticated, but after login gets redirected to the access denied page. the session was created, because the user was able to perform other permitted actions and the log shows a successful authentification (enabeld spring secured log on debug level). so why does the redirect to the access denied page happen?
tocmat 7.x assumes that no cookies are activated and adds the sessionid to the redirect url and addtionally set the cookie via "set cookie" http header. that's the point where the spring security plugin is confused.
http response of j_spring_security_check
HTTP/1.1 302 Moved Temporarily
Connection: Keep-Alive
Content-Length: 0
Date: Fri, 14 Oct 2011 06:41:59 GMT
**Location: https://myserver/main;jsessionid=8341CD832CAF4569A95BBF436395744E**
Server: Apache-Coyote/1.1
**Set-Cookie: JSESSIONID=8341CD832CAF4569A95BBF436395744E;** Path=/etsweb/; HttpOnly
followed by a http get https://myserver/main;jsessionid=8341CD832CAF4569A95BBF436395744E
http response
HTTP/1.1 302 Moved Temporarily
Connection: Keep-Alive
Content-Length: 0
Date: Fri, 14 Oct 2011 06:41:59 GMT
Location: https://myserver/login/denied
Server: Apache-Coyote/1.1
the solution was to disable url rewriting by setting following tag in web.xml file
<session-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
I don't know whether this is a spring sec bug or a thinking bug.
Also, make sure wild card in your security settings is using IS_AUTHENTICATED_ANONYMOUSLY, and not ROLE_ANONYMOUS.
'/**': ['IS_AUTHENTICATED_ANONYMOUSLY']
Related
I followed this 3 parts tutorial and successfully deployed a Rails app in a Managed Digital Ocean App.
Locally, I can use httpie to GET resources and POST to create new users such as:
http :8080/signup name=test email=test#email.com password=foobar password_confirmation=foobar
But, once deployed on digital ocean with at this url with valid TCP health check, I try to create an user (with http/postman):
http mtserver-igkkx.ondigitalocean.app:8080/signup name=test email=test#email.com password=foobar password_confirmation=foobar
and end up with:
HTTP/1.1 301 Moved Permanently
CF-RAY: 6d851c0f7951408d-CDG
Cache-Control: max-age=3600
Connection: keep-alive
Date: Fri, 04 Feb 2022 16:00:02 GMT
Expires: Fri, 04 Feb 2022 17:00:02 GMT
Location: https://mtserver-igkkx.ondigitalocean.app/signup
Server: cloudflare
Transfer-Encoding: chunked
Vary: Accept-Encoding
Assuming I need to prefix the URL with https, i try again with:
http https://mtserver-igkkx.ondigitalocean.app:8080/signup name=test email=test#email.com password=foobar password_confirmation=foobar
And end up with:
http: error: SSLError: HTTPSConnectionPool(host='mtserver-igkkx.ondigitalocean.app', port=8080): Max retries exceeded with url: /signup (Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:997)'))) while doing a POST request to URL: https://mtserver-igkkx.ondigitalocean.app:8080/signup
If I try a POST with postman:
POST > mtserver-igkkx.ondigitalocean.app:8080/signup?name=test&email=test#mail.com&password=foobar&password_confirmation=foobar
it returns:
{
"status": 404,
"error": "Not Found"
}
While visiting the server URL on '/' it returns a 404 but I assume it's normal as it's only supposed to work in API mode and no route currently handles /.
I'm Looking forward to understand how to handle digital ocean in production to be able to create users on this API through http requests.
For the record, ssl was the problem.
You need to go through the process of adding a SSL certificate through digital ocean so https (and further your web app) works when you query the prefixed url.
This unanswered SO post helped me a lot to figure out the good process.
After an Artifactory upgrade to 7.4.1 from 6.10.4, I've made the necessary port changes and the UI works fine, but I'm seeing the following in the artifactory-service log when attempting to use docker login via the subdomain method:
Request /v2/ should be a repo request and does not match any repo key
The docker login command prompts for authentication but then returns:
Error response from daemon: login attempt to http://<local-docker-repo>.<artifactory-url>.com/v2/ failed with status: 404 Not Found
Artifactory is running in a Kubernetes cluster behind an nginx ingress controller, which has an ingress set up specifically to serve https://<local-docker-repo>.<artifactory-url>.com via the same backend as the Artifactory UI. It seems like some URL rewrite functionality is not working, I'm just not sure how I've misconfigured it as I had no problems in the previous version.
Curl results as follows:
curl -i -L -k http://docker-local.<artifactory-url>.com/v2/
HTTP/1.1 308 Permanent Redirect
Server: nginx/1.15.9
Date: Mon, 21 Sep 2020 00:25:32 GMT
Content-Type: text/html
Content-Length: 171
Connection: keep-alive
Location: https://docker-local.<artifactory-url>.com/v2/
X-JFrog-Override-Base-Url: ://docker-local.\<artifactory-url>.com:80
X-Forwarded-Port: 80
Host: docker-local.artifactory.<artifactory-url>.com
X-Forwarded-For: 10.60.1.1
HTTP/2 401
server: nginx/1.15.9
date: Mon, 21 Sep 2020 00:25:32 GMT
content-type: application/json;charset=ISO-8859-1
content-length: 91
www-authenticate: Basic realm="Artifactory Realm"
x-artifactory-id: ea0c76c54c1ef5de:45761df0:174ad9a6887:-8000
x-artifactory-node-id: artifactory-0
x-jfrog-override-base-url: ://docker-local.<artifactory-url>.com:443
x-forwarded-port: 443
host: docker-local.<artifactory-url>.com
x-forwarded-for: 10.60.x.x
strict-transport-security: max-age=15724800; includeSubDomains
{
"errors" : [ {
"status" : 401,
"message" : "Authentication is required"
} ]
Any help would be greatly appreciated!
Edit: As a workaround I've enabled Repository Path as the Docker access method, which works fine -- still not sure where subdomain is going wrong.
The issue was that the $repo variable in the nginx rewrite rules provided by Artifactory was not getting populated for some reason. Since we only have a single registry being used in the subdomain method, I updated the rewrite rule to provide the repo name which resolved the issue.
To illustrate:
rewrite ^/(v1|v2)/(.*) /artifactory/api/docker/$repo/$1/$2;
was changed to:
rewrite ^/(v1|v2)/(.*) /artifactory/api/docker/docker-local/$1/$2;
I have successfully registered my application for graph.microsoft.com, but now it also needs to work with graph.cloudapi.de.
The Application Registration Portal does not seem to be the correct one for the German National Cloud.
Moreover, applications registered in portal.microsoftazure.de only work with the SharePoint API, not Graph.
Here's a sample HTTP exchange between my program and the German Microsoft Cloud. I am hand coding HTTP requests in Delphi. The exchange works with graph.microsoft.com, but not graph.microsoft.de.
I start the authentication via the following https URL:
login.microsoftonline.de/common/oauth2/v2.0/authorize?response_type=code&client_id=xyz&prompt=login&scope=https%3A%2F%2Fgraph.microsoft.de%2Fuser.read%20&response_mode=query&state=5736109994698155204&redirect_uri=https%3A%2F%2Fwww.syncovery.com%2Foauthresult.php
The cloud then directs to my redirect URL with a long code parameter, such as
code=AQABAAIAAQDnLpu3ikefR73l_aNlxt5xxdvNhQ9JVAI7b0ciTej............
So far, so good. Now the hard part:
POST /common/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.de
Keep-Alive: 300
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 805
client_id=xyz&client_secret=abc&code=AQABAAIAAQD_very_long&redirect_uri=https%3A%2F%2Fwww.xyz.com%2Foauthresult.php&grant_type=authorization_code&scope=https%3A%2F%2Fgraph.microsoft.de%2Fuser.read%20
Reply:
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
x-ms-request-id: e83986c0-5da4-4af7-92fc-46e2fb950100
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: esctx=AQABAAAAA_longish domain=.login.microsoftonline.de; path=/; secure; HttpOnly
X-Powered-By: ASP.NET
Date: Wed, 07 Feb 2018 11:11:44 GMT
Content-Length: 449
{
"error": "invalid_client",
"error_description": "AADSTS70002: Error validating credentials. AADSTS50012: Invalid client secret is provided.\r\nTrace ID: e83986c0-5da4-4af7-92fc-46e2fb950100\r\nCorrelation ID: 044f44e3-ec09-4f76-b073-0ff6b72b696a\r\nTimestamp: 2018-02-07 11:11:45Z",
"error_codes": [70002, 50012],
"timestamp": "2018-02-07 11:11:45Z",
"trace_id": "e83986c0-5da4-4af7-92fc-46e2fb950100",
"correlation_id": "044f44e3-ec09-4f76-b073-0ff6b72b696a"
}
The apps.dev.microsoft.com portal is global, there isn't a national cloud instance of the portal. You do however need to register your app under an AAD account using "Azure AD only applications" rather than "Converged applications". This is because the v2 Endpoint itself isn't supported by national cloud endpoints yet.
Another problem here is that your URI is also incorrect.
Some notes from the documentation related to Germany:
Microsoft Graph Root Endpoint: https://graph.microsoft.de (not graph.cloudapi.de)
OAuth2.0 Endpoint: https://login.microsoftonline.de
The Azure AD v2.0 authorization and token endpoints are available on the global service only; they are not yet supported for use with national cloud deployments.
I have a WebAPI service deployed on a server. There is also an MVC app for testing the API. One such tester runs on my dev machine and another copy (same version) runs on the server where API resides.
The MVC tester app supports calling API directly and also through a built-in 'proxy' (http handler) to bypass the "Access-Control-Allow-Origin" errors. So for example if I run the tester app on my dev machine and I want to receive data from the server, I must use the proxy. This setup works nicely and all of the calls are going through and data is passed properly.
Problem occurs when I don't provide enough inputs (for testing purposes) and API generates a "400 Bad request" error. It only happens when I make a call from my dev machine to remote machine and works fine if I make the same call on the server.
I tested with Postman on the remote server:
post directly to API: POST to 177.77.77.77/v1/feature {JSON payload}
the response I get back contains proper headers, a body with a JSON object describing the error. Same thing happens when I send the same exact command but through server's proxy:
post through proxy: POST to 177.77.77.77/proxy/feature {JSON payload}
both results are identical and this is the expected behavior, which I think allows to make a conclusion that proxy is working and API is working.
When I go back to my dev machine and try the same calls, my result for posting directly to API is the same as above but if I use the server's proxy something else happens. Here's output from Fiddler for the working case (from dev machine directly to API):
POST http://177.77.77.77/v1/feature HTTP/1.1
Host: 177.77.77.77
Connection: keep-alive
Content-Length: 514
User-Agent: Mozilla/5.0 xx..
Cache-Control: no-cache
Origin: chrome-extension://xx-postman-xx
Authorization: Basic pwd=
Content-Type: application/json
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
{payload}
response:
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 30 Mar 2015 15:48:52 GMT
Content-Length: 139
{"code":"INVALID_REQUEST","message":"proper error message"}
this is the correct behavior with expected message body (JSON) and correct content-lenght. If I make a request to the server's proxy, my request becomes:
POST 177.77.77.77/proxy/feature HTTP/1.1
Host: 177.77.77.77
Connection: keep-alive
Content-Length: 514
User-Agent: Mozilla/5.0 xx..
Cache-Control: no-cache
Origin: chrome-extension://xx-postman-xx
Authorization: Basic pwd=
Content-Type: application/json
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: appSettings=xx
{payload}
then the response I get is:
HTTP/1.1 400 Bad Request
Cache-Control: private
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 30 Mar 2015 15:51:37 GMT
Content-Length: 11
Bad Request
the body/payload of the response is lost or replaced by status, content-type changed from JSON to text/html and cache-control became private.
The cookie in the non-working case plays no role. I tried removing it and result is still wrong.
Why do you think this is happening? How can I troubleshoot this and find what portion of code (or maybe IIS setting?) is responsible for sending a different response for what seems to be same requests? After all everything works fine when I run only on dev or only on remote. Could this be some permission issue or something in IIS on the server?
I tried remote-debugging of the proxy code where I would step through the code while sending Post commands (with the same payload) through Postman. In one scenario I ran Postman on the server and made a request to server's proxy and in another scenario I ran Postman on dev and also made requests to server's proxy. In VS I can see that I'm going through the same path in code for both scenarios and that API's response is the same.
Thanks for reading and any attempts to help will be greatly appreciated!
added this to web.config:
<system.webServer>
<httpErrors existingResponse="PassThrough"></httpErrors>
</system.webServer>
found the solution here:
In IIS7.5 what module removes the body of a 400 Bad Request
I'm building an open API with rails and hosting my project on Heroku. However I want my API calls to be from mydomain.co instead of heroku's domain.
I added my domain from Heroku dashboard, and I also forwarded my domain to heroku's url.
However when I make the 'POST' call like below:
curl -H "Content-Type: application/json" -d '{"myjsontitle":{"field1":"eerbil.eren#derivalabs.com","field2":"12345678"}}' -X POST http://deriva.co/applicants.json
Terminal returns the following:
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
And when I look at the heroku logs, it says
at=info method=GET path="/applicants.json" host=stark-bayou-1773.herokuapp.com
How should I fix that problem?
Thanks!
There is an error with your DNS configuration.
➜ ~ curl -I deriva.co
HTTP/1.1 302 Found
Cache-Control: max-age=900
Content-Type: text/html; charset=utf-8
Location: https://stark-bayou-1773.herokuapp.com
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 02 Feb 2015 19:59:45 GMT
Content-Length: 155
Age: 67
Connection: keep-alive
deriva.co redirects to Heroku, whereas it should resolve to it. You probably used a sort of provider redirect, which is not the correct DNS configuration. You need to "point" the DNS to Heroku.
Please note that you can't map deriva.co to Heroku directly unless your providers supports a CNAME-like configuration for the root domain. And GoDaddy does not.
You either need to change DNS provider or point www.deriva.co using a CNAME and redirect deriva.co to www.deriva.co.