When I access Jenkins trough an EC2 I get an error - amazon-web-services

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.

Related

How to get fixedresponseconfig on boto3 to work?

I am trying to create an integration between EC2-ALB and Lambda functions and in a part of my code I am trying to use the method:
modify_listener() documentation available here: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/elbv2.html#ElasticLoadBalancingv2.Client.modify_listener
in that part I am using the DefaultAction: FixedResponseConfig where I am trying to display a simple hello world on html. the way this gets triggered in the code is, if my target group is unhealthy display the fixed response permissions have been setup everything looks fine because when I run the function I get a successful message but when I ask for the application from my okta portal I don't get that response (hello world) I get a normal 503 service temporary unavailable.
How can I direct that fixed response to the frontend of the app when is not working? the purpose of this is to display a maintenance page when the target group is down.
Thanks for the responses please feel free to make any question.
You can't customize ALB's error messages through fixed response. Instead you should consider two options:
use CloudFront in front of your ALB to setup Custom Error Page for Specific HTTP Status Codes
use Route53 DNS failover when your ALB becomes unhealthy.

When trying to deploy my nodejs code to gcloud, the url I am deploying to gives a 502 error

First, when trying to deploy my code to the target url in gcloud, the deployment process hangs.
The target url has the suffix appspot.com.
When I ping the target url, I get a request timeout. When I type the target url in my browser, I get a 502 error: server error.
When I deployed the same code to a different test environment in dialogflow, everything seemed to work fine. However when I try deploying again to this url (it is the correct url obtained from the webhook fulfilment url in dialogflow), I get this error:
Updating service [default] (this may take several minutes)...failed.
ERROR: (gcloud.app.deploy) Error Response: [4] Timed out waiting for
the app infrastructure to become healthy.
Everything else, including the node js code and the dialogflow configurations are the same between the two environments I am deploying to, except for the webhook fulfilment url.
Does anyone know what the issue can be narrowed down to? And please let me know if I can include any more useful information.
My guess is that the server is down for that specific URL. One thing to note is that I am using V1 dialogflow.
Resolved, it ended up being a firewall issue for that specific url.

Stopped & Started AWS EC2 instance from Console, now my app won't load

Through the console, I stopped and restarted an instance after making some very minor changes to the code. However when I went back to the domain and refreshed the page, I received the following error: 'This site can’t be reached'
Does anyone know what I have done wrong or can do to get it back working?
I would validate the public DNS name to see if it got changed
You might also want to check the firewall settings

Google: Permission denied to generate login hint for target domain NOT on localhost

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

Using Meteor browser-policy package allowOriginForAll for AWS works on http site but not https

So we are using the Meteor browser-policy package, and using Amazon S3 to store content.
On the server we have setup the browser policy as follows:
BrowserPolicy.content.allowOriginForAll('*.amazonaws.com');
BrowserPolicy.content.allowOriginForAll('*.s3.amazonaws.com');
This works fine in local dev and in production when visiting our http:// site. However when using the https:// address to our site the AWS content no longer passes this policy.
The following error is put on the console
Refused to load the image 'http://our-bucket-name.s3.amazonaws.com/asset-stored-in-s3.png' because it violates the following Content Security Policy directive: "img-src data: 'self' *.google-analytics.com *.zencdn.net *.filepicker.io *.uservoice.com *.amazonaws.com *.s3.amazonaws.com".
As you can see we have some other origins allowed in the browser policy, these all seem to work fine in both http and https. AWS S3 is the only one that is failing.
I've tried Chrome, Firefox, and Safari and they all have the same issue.
Whats going on?
I may not have the exact answer to this question but I have some information which the community may find helpful.
First, you should avoid serving mixed content. I'm unclear if that would set off the browser policy alerts but you just shouldn't do it anyway. The easiest solution is to use a protocol-relative-url or just explicitly specify https in your url.
Second, I too assumed that the wildcard worked like a glob. However, I've been told that it works the same way as an ssl certificate rule - i.e. for all subdomains or for a specific subdomain. In other words, *.example.com and www.example.com, are valid but *.foo.example.com, isn't meaningful. I think you want to explicitly add your bucket like so:
BrowserPolicy.content.allowOriginForAll('our-bucket-name.s3.amazonaws.com')
unless you literally want to trust all of amazonaws.com.