Kaa REST log appender issue - kaa

I have configured REST appender on DataCollectionDemo on the Sandbox. I have configured host = localhost, "/" at the end and beginning of URI path, no ssl. I have a http listener running on my localmachine. I have also disabled firewall on my machine. Now I cant receive the POST method on my server. Please help.

Key errors faced and their solutions while deploying Kaa REST log appender:
Error 500: I found two errors with my configuration of RestLogAppender in the admin panel. First, I had put http:// before my host. Had to remove the same. Second, I should have mentioned Relative URI path starting and ending with a forward slash /.
Error 400: I had given slightly different names to the JSON fields in the Django models. The sequence of the fields did not matter but the name of fields did matter.

Related

Configuring Keycloak OIDC with an nginx (OpenResty) reverse-proxy

I am experimenting with a two-service docker-compose recipe, largely based on
the following GitHub project:
https://github.com/rongfengliang/keycloak-openresty-openidc
After streamlining, my configuration looks something like the following fork
commit:
https://github.com/Tythos/keycloak-openresty-openidc
My current issue is, the authorization endpoint ("../openid-connect/auth") uses
the internal origin ("http://keycloak-svc:"). Obviously, if users are
redirected to this URL, their browsers will need to cite the external origin
("http://localhost:"). I thought the PROXY_ADDRESS_FORWARDING variable for the
Keycloak service would fix this, but I'm wondering if I need to do something
like a rewrite on-the-fly in the nginx/openresty configuration.
To replicate, from project root::
docker-compose build
docker-compose up --force-recreate --remove-orphans
Then browse to "http://localhost:8090" to start the OIDC flow. You can
circumvent the origin issue by, once you encounter the aforementioned origin
issue, by replacing "keycloak-svc" with "localhost", which will forward you to
the correct login interface. Once there, though, you will need to add a user
to proceed. To add a user, browse to "http://localhost:8080" in a separate tab
and follow these steps before returning to the original tab and entering the
credentials:
Under Users > Add user:
username = "testuser"
email = "{{whatever}}"
email verified = ON
Groups > add "restybox-group"
After user created:
Go to "Credentials" tab
Set to "mypassword"
Temporary = OFF
Authorization Servers such as Keycloak have a base / internet URL when running behind a reverse proxy. You don't need to do anything dynamic in the reverse proxy - have a look at the frontend URL configuration.
Out of interest I just answered a similar question here, that may help you to understand the general pattern. Aim for good URLs (not localhost) and a discovery endpoint that returns intermet URLs rather than internal URLs.

WooCommerce - Auto generating API keys using our Application Authentication Endpoint give 401 Invalid URL error

I'm attempting to use the REST API provided by WooCommerce to generate the Customer Secret and Customer Key values so that it could be used to invoke other WooCommerce REST APIs. I referred the documentation about generating the key values and managed to get it working using a mock endpoint in Postman used for the call_back URL in the API as mentioned in the document.
I created a POST service in my backend server and managed to setup a SSL certificate in the local environment with a domain mapped in hosts file in /etc directory. I ran the backend service and invoked the callback url through Postman and it worked. Then I used that as the call_back URL in the actual WooCommerce Auth endpoint to programatically generate the keys and save it in my DB. But I'm getting
"Access Denied" - Error: A valid URL was not provided..
When I checked the browser through devtools -> network noticed that there is a 401 Unauthorize error.
Here is the sample GET URL that is uesd for WooCommerce API key generation
http://localhost/woocommerce/wc-auth/v1/authorize?app_name=<SOME_NAME>&scope=read_write&user_id=36&return_url=http://localhost/woocommerce/&callback_url=https://foo.bar.dev:44329/api/services/app/woo_commerce_auth/6/callback
callback_url = https://foo.bar.dev:44329/api/services/app/woo_commerce_auth/6/callback
When the callback_url is a mock url generated using Postman it works fine
callback_url = https://513ca6ab-db16-4635-8d0b-9159e3b1e187.mock.pstmn.io/api/services/app/woo_commerce_auth/6/callback
Any clue why this happens, I could not find a way to troubleshoot this issue. Appreciate the help.
Hi posting this for future reference, and hope it would help others who face this problem as well.
Things to keep in mind when setting the callback_url,
Non HTTPS URL endpoint are not allowed.
URL should not be a localhost url (e.g localhost/callback would give an invalid URL error)
URL should not contain port number (e.g localhost:4320/callback or foo.bar.dev:4892/callback are invalid)
Callback URL should be a POST url
If an error such as Error: An error occurred in the request and at the time were unable to send the consumer data. is given after checking all the above check the backend service code related to the callback_url (I had a 500 server error which triggered this, it was not a WooCommerce issue)
Also a tool such as ngrok would be really helpful to setup an HTTPS endpoint in your local environment to test this.

Rest api returns error 403 while calling from Wordpress but works in postman

I have one server on which Apache and Tomcat both are installed to run my Wordpress and Java application respectively. Both are on same ip address and using same domain https://www.example.com only port number is different.
Wordpress is running on default port while Tomcat is runing on 8443.
A rest api on Tomcat https://www.example.com:8443/myApi.html is working fine from postman, but when calling from wordpress using ajax, it returns error 403 forbidden response.
I am stuck on searching its solution but failed.
Please help me out to solve this issue.
Thanks
You cannot use a different port, even when using the same domain. This breaks the Same origin policy.You can however use JSONP if you have access to both the daemon and the requesting site. If data needs to be returned, then the daemon needs to support a callback query parameter and return it properly formatted.
please see 1) https://stackoverflow.com/a/2099771
https://stackoverflow.com/a/2099784

Microsoft application - Redirect URI allows 'localhost' but not '127.0.0.1'

I have developed an application that allows MSA (Microsoft Account) authentication. I have registered my app here: https://apps.dev.microsoft.com.
When testing my app locally, I can access my app with no problem at my SSL URL of https://localhost:44300, and MSA works fine. When I registered my app, I used https://localhost:44300/signin-microsoft as the Redirect URI.
Problem: I can also access my app at https://127.0.0.1:44300, as one would expect. However, MSA here doesn't work. The error page says, We're unable to complete your request.
Microsoft account is experiencing technical problems. Please try again later. And the URL of the error page reveals that the error is with a mismatch in the Redirect URI: https://login.live.com/err.srf?lc=1033#error=invalid_request&error_description=The+provided+value+for+the+input+parameter+'redirect_uri'+is+not+valid.+The+expected+value+is+'https://login.live.com/oauth20_desktop.srf'+or+a+URL+which+matches+the+redirect+URI+registered+for+this+client+application.
In the Microsoft Apps page, when I try to update the Redirect URI from https://localhost:44300/signin-microsoft to https://127.0.0.1:44300/signin-microsoft, it doesn't allow me to save my change and it shows me this error: Your URL can't contain a query string or invalid special characters, and it provides a 'Learn More' link: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-v2-limitations#restrictions-on-redirect-uris
After reading the info in this link, I see nowhere that a URI like mine (https://127.0.0.1:44300/signin-microsoft) would be an unacceptable URL, as I'm not breaking any of their rules: I have no invalid characters, no query strings, etc.
My research: Looking online, people are getting the Your URL can't contain a query string or invalid special characters because they are actually using a query string or invalid special characters, such as in this link: https://social.msdn.microsoft.com/Forums/en-US/4f638860-ea57-4f0e-85e0-b28e1e357fe2/office-365-app-authorization-redirect-uri-issue?forum=WindowsAzureAD. I couldn't find a case where someone has entered a valid URI and they weren't allowed to save it.
Why I need 127.0.0.1 to work: I need to expose this website, which is running on my local box. In order to have the website running without having an instance of Visual Studio opened all the time, I'm using csrun to host my website in Azure local fabric (by the way, my app is an Azure Cloud Service, with a ASP.NET MVC 5 app as a web role). I followed this instruction for csrun: http://www.bardev.com/2013/03/12/how-to-deploy-application-to-windows-azure-compute-emulator-with-csrun/. Using csrun, it allowed me to host my website in https://127.0.0.1:444 (but, as with https://127.0.0.1:44300, MSA doesn't work). My end goal is to expose this website with a public URL using ngrok (https://www.sitepoint.com/use-ngrok-test-local-site/), so that anyone can access my site.
Therefore, my main question is: how can I have the Redirect URI be https://127.0.0.1:44300/signin-microsoft instead of https://localhost:44300/signin-microsoft?
Make sure you access this portal through https://identity.microsoft.com as this is the only way the steps below will work.
You can get around this error right now by adding the reply URL through the manifest. Login to the portal, select the app you want to configure, and scroll down and hit the Edit Application Manifest button. Then you can add your https://127.0.0.1:44300/ to the replyUrls field.
There's some funny behavior that will only allow this right now if you only register other localhost reply Urls. If this is the only reply URL you need then it shouldn't be a problem.

subdomain | ASP.NET | Server Error in '/' Application

I am having problems using a subdomain and ASP.NET, I guess it must be something very simple I just do not know what.
If you would like to go right to the point just jump to no. 7 below...
TVM, RConte
My hosted domain:
Hosted Service Domains: MYDOMAIN.net
Added a subdomain: (rfpesquisa)
Sub Domains
Sub Domain Remove
rfpesquisa Remove [THIS ONE]
Added a "A" record in DNS [see below]
Hosted DNS MYDOMAIN.net
$ORIGIN MYDOMAIN.net.
$TTL 86400
.....etc
rfpesquisa 86400 IN A 174.36.13.167 [THIS ONE, COPIED FROM...]
www 86400 IN A 174.36.13.167 [...THIS ONE]
TESTS MADE:
Acessed main page (not the subdomain) as usual:
(http://)www.MYDOMAIN.net/AcessaPesquisa.aspx
works fine !
Added a "kkk" so as to make for a wrong url:
(http://)www.MYDOMAINkkk.net/AcessaPesquisa.aspx
gives:
"Could not locate remote server" [as expected]
Tried a non-existing subdomain, XXXXXX
(http://)XXXXXX.MYDOMAIN.net/AcessaPesquisa.aspx
gives:
HTTP Error 404. The requested resource is not found.
[witch means to me that the server was found but the subdomain per se was not found]
Tried what I am look for dooing: (used the subdomain rfpesquisa)
(http://)rfpesquisa.MYDOMAIN.net/AcessaPesquisa.aspx
Message I got:
Server Error in '/' Application.
The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested URL: /AcessaPesquisa.aspx
given that ASP.NET Message, it means to me that
--the subdomain WAS found,
the request was given to ASP.NET dll, only
it is NOT pointing to the same place as the domain, otherwise
the results for this try and no.4, the rigth one, would be the same.
file "AcessaPesquisa.aspx" is NOT in the target directory.
Please, how do I point the subdomain to the right place ?
Thank you very much,
Ricardo Conte
I guess
(1) you are using pan-domain service (one of DNS registry, redirecting requests to all sub-domains *.mydomain.net to the same server)
AND
(2) in your IIS configuration of this server, you've bound the website and the host name "www.mydomain.net" together.

Resources