I am trying to figure out how to get monitoring to work in Postman.
I have written tests on the desktop client for get/create/put and everything works fine. I'm using a localhost address and port 5004 which is the port for the API.
http://127.0.0.1:5004/bookings
I have tried to change the proxy in setting to localhost and port 5004, I have tried to change it to 127.0.0.1:5004, I have tried to disable SSL on the desktop client. I am running the monitoring on using the desktop client from the browser, that doesn't work either.
I have also checked if my etc/host file contains 127.0.0.1 localhost and it does.
Not sure what else I can try, I would appreciate any help. :)
Accessible APIs:
Monitors require all URLs to be publicly available on the internet as
they run in the Postman cloud. A monitor cannot directly access your
localhost or run requests behind a firewall. However, to overcome this
issue, static IPs are available on Postman Business and Enterprise
plans.
https://learning.postman.com/docs/designing-and-developing-your-api/monitoring-your-api/intro-monitors/
you cannot use the monitor for inhouse and localhost websites, You could upgrade to enterprise or business plans and see if that helps
The issue is maybe you configured the environment variable and passed the correct value in the URL also
But while running the collection test class
didn't select the correct environment
Select the environment configured to run that collection, shown in attached screenshot
I faced this problem and the issue was my DNS address. After changing the DNS server it was solved.
I had the same problem, I had space between ip and :port =>0.0.0.0b:1111 in my env. I deleted the space and I can connect. => 0.0.0.0:1111.
I faced the same issue and it got solved by removing the env variable
what you should try is sign out, sign in again. make sure the environment variables are not empty.
also, try using the feature console.log(get environment variable name) it would be helpful.
make sure to click on persist all in the environment variable.
The key for me was to click on "persist all" in the environment variable
read the github
some comments which helped me resolve the issue
I got an issue. I created a Jenkins AMI that i snapshoted it and created an image from a running ec2 instance with an already configured Jenkins Master on port 8443 with an https certificate. But when I curl to the jenkins instance i get the following:
[1]: https://i.stack.imgur.com/K2tz0.png
I checked Jenkins logs and everything was normal. And my Elatic Load balancer is healthy which means the security groups and other things are working just fine. Does anybody have a clue why is it giving a 403 Forbidden? Another point is that I can even access the GUI
By using curl you're making your life harder but look at some of what comes back:
<meta http-equiv='refresh' content='1;url=/login?from=%2F'/>
If you've done HTML programming, this is one way of having the browser execute a redirect. Why Jenkins doesn't do some sort of HTTP redirect I don't know but the code is telling you that, after 1 second, redirect to the url /login.
curl isn't going to interpret the HTML for you, unlike the browser. Jenkins is working fine - you just need to follow what the HTML and JavaScript code is telling you to do through curl.
The 403 error is the Jenkins application specifically saying your current user is not allowed access to the current action.
It appears you’re not logged in so your action is treated as an anonymous user. If the anonymous user should have the permissions to access this action you will need to add them.
I'm trying to follow the instructions on https://cloud.google.com/storage/docs/hosting-static-website to host a static website from a Google Bucket. I've created the CNAME alias, uploaded the content to a bucket named the same as the website (www.kurtpeek.com), and checked "Share publicly" for all items. However, when I browse to the website I see the following:
I've read on http://tekhoow.blogspot.be/2015/12/soving-accessdenied-on-google-cloud.html that this problem can be solved from the command line using gsutil. However, I've done it before for a different website using the web-based console, I just don't remember how.
I suspect it should be somewhere in the "IAM" menu, but I can't seem to find the 'read public' options similar to the commands.
Can anyone point out the 'missing ingredient' to make the website work?
I finally did use the command-line solution:
~$ gsutil web set -m index.html gs://www.kurtpeek.com
Setting website configuration on gs://www.kurtpeek.com/...
and now the website works as expected.
I am trying to create a Google sign-in and getting the error:
Permission denied to generate login hint for target domain
Before you mark this a duplicate, this is not the same as the question asked at Google sign in website Error : Permission denied to generate login hint for target domain because in that case the questioner was on localhost, whereas I am getting this error on the server.
Specifically, I have included the url of the server in the Authorized Javascript Origins, as in the following image:
and when I get the error, the request shows that the same url was sent, as in the following image:
Is there something else I should be putting in my Restrictions page? Is there any way to figure out what is going on here? Is there a log at the developer console that can tell me what is happening?
Okay, I figured this out. I was using an IP address (as in "http://175.132.64.120") for the redirect uri, as this was a test site on the live server, and Google only accepts actual urls (as in "http://mycompany.com" or "http://localhost") as redirect uris.
Which, you know, THEY COULD HAVE SAID SOMEWHERE IN THE DOCUMENTATION, but whatever.
I know this is an old question, but it's the first result when you look for the problem via Google, so I'll share my solution with you guys.
When deploying Google OAuth service in a private network, namely some IP that can't be accessed via the Internet, you should use a magic DNS service, like xip.io that will give you an URL that your browser will resolve to your internal IP. You see, Google needs to be able to reach your authorized origin via your browser, that's why setting localhost works if you're serving it on your computer, but it won't work when you're deploying outside the Internet, as in a VPN, intranet, or with a tunnel.
So, the steps:
get your IP address, the one you're deploying at and it's not a public domain, let's say it's 10.0.0.1 as an example.
add http://10.0.0.1.xip.io to your Authorized Javascript Origins on the Google Developer Console.
open your site by visiting http://10.0.0.1.xip.io
clear your cache for the site, if necessary.
Log in with Google, and voilà.
I got to this solution using this answer in another question.
If you are using http://127.0.0.1/projects/testplateform, change it into http://localhost/projects/testplateform, it will work just fine.
If you testing in your machine (locally). then dont use the IP address (i.e. http://127.0.0.1:8888) in the Client ID configuration , but use the local host instead and it should work
Example: http://localhost:8888
To allow ip address to be used as valid javascript origin, first add an entry in your /etc/hosts file
10.0.0.1 mydevserver.com
and then add this domain mydeveserver.com in Authorized Javascript Origins. If you are using some nonstandard port, then specify it with your domain in Authorized Javascript Origins.
Note: Remove your cache and it will work.
Just ran across this same issue on an external test server, without a DNS entry yet. If you have permission on your local machine just edit your /etc/hosts file:
175.132.64.120 www.jimboweb.com
And use use http://www.jimboweb.com as an authorized domain.
I have a server in private net, ip 172.16.X.X
The problem was solved with app port ssh-forwarding to my localhost port.
Now I am able to use deployed app with google oauth browsing to localhost.
ssh -N -L8081:localhost:8080 ${user}#${host}
I also add localhost:8081 to "Authorized URI redirect" and "Authorized JavaScript sources" in console.developers.google.com:
google developers console
After battling with it for a few hours, I found out that my config in the Google Cloud console was all correct and similar to the answers provided. Due to caching issues or something, I had to recreate a OAuth Client ID and then it suddenly started working.
Its a pretty old issue, but I encountered it and there wasn't any helpful resource, as such I am posting my solution.
For me the issue was when I hosted my web-app locally, a using google-auth for logging in.
The URL I was trying to hit was :- http://127.0.0.1:8000/master
I just changed from IP to http://localhost:8000/master/
And it worked. I was able to log in to the website using Google Auth.
Hope this helps someone someday.
install xampp and run apache server,
put your files (index and co) in a folder in the xampp dir (c:\xampp\htdocs\yourfolder).
Type this in your browser url - http://localhost/yourfolder/index.html
I'm evaluating WSO2 Identity Server 5.0.0 but I'm getting a strange issue using the dashboard.
I installed it on a server of mine (so it is not on localhost) and configured the following configuration files so that WSO2 knows where to point
File wso2is-5.0.0/repository/conf/carbon.xml
<HostName>SERVER_IP</HostName>
<MgtHostName>SERVER_IP</MgtHostName>
File wso2is-5.0.0/repository/conf/security/saml2.federation.properties
WSO2=https://SERVER_IP:9445/samlsso
File wso2is-5.0.0/repository/conf/security/sso-idp-config.xml
<SSOIdentityProviderConfig>
<ServiceProviders>
<ServiceProvider>
<Issuer>wso2.my.dashboard</Issuer>
<AssertionConsumerService>https://SERVER_IP:9443/dashboard/acs</AssertionConsumerService>
...
As stated in the official documentation I should see some blocks and after clicking the "View details" buttons I should be able to do the operations of the dashboard related to each block.
However, when I login in the Dashboard I can see the blocks, but when I click "View details" I get a blank-content page a you can see in the following screenshot of the "My Profiles" page
The same thing happens for the other blocks.
What can I do? Maybe I didn't configure something?
Thank you in advance
Giulio
If you have installed the identity server other than localhost, You would see some issues with dashboard. I also experienced same type of issues. But you can resolve them by configuring the host name and port properly. Unfortunately there are few places that you need to edit. Please find them below. I have already to report a jira to improve them to configure from one config file.
repository/conf/carbon.xml
repository/conf/security/sso-idp-config.xml
repository/deployment/server/jaggeryapps/dashboard/apis/gadget.json
repository/deployment/server/jaggeryapps/portal/gadgets/account-recovery/gadget.xml
repository/deployment/server/jaggeryapps/portal/gadgets/identity_management/gadget.xml
repository/deployment/server/jaggeryapps/portal/gadgets/pwd_change/gadget.xml
repository/deployment/server/jaggeryapps/portal/gadgets/user_auth_apps/gadget.xml
repository/deployment/server/jaggeryapps/portal/gadgets/user_profile/gadget.xml
modify the url of the user_profile (i.e. http://{IP}:{port}/portal/gadgets/user_profile/gadget.xml ) in "repository/deployment/server/jaggeryapps/dashboard/apis/gadget.json" file in to HTTP and Port in to 9763.