I'd like to direct traffic to different versions of Google App Engine code based on a set list of known IP Addresses.
For example, if an incoming request is from an IP Address on a given list, then traffic is directed to version 1. If not, then version 2.
Is there a way to do this from the admin console or deployment configuration?
The end goal is to grant access to extra features when the site is accessed from an approved IP Address. If I can't do this from the admin console, then I plan to get the IP Address during the user's login process, and set their security role based on IP.
There's not a way within the admin console or deployment process. However, if you do cookie-based traffic splitting, you can set the cookie yourself (based on the incoming IP address, or another value you desire). The value is stored in GOOGAPPUID and the value you'd want to use is described in the documentation, and varies depending on the number of versions you're splitting between and the respective levels of traffic you'd like to send to each version.
If you don't want to do traffic splitting for users not on a given list of IPs, you should make sure to explicitly set the cookie for all users. Otherwise, App Engine will provide the value (and send some users to both versions) by default.
Related
getting this error , Oauth2 failed.Invalid credentials. its due to IP restriction. plaese share IP ranges for salesforce ELF browser.
IP login ranges are set per Salesforce org and optionally per Profile. They are not universal and have nothing in particular to do with the Event Log File browser.
You need to speak with your local Salesforce administrator for information about the configuration of your org.
My initial answer (above) did not reflect awareness that "event log file browser" refers to a third-party Heroku application. It would be helpful to be specific in the question.
Heroku applications in general do not have static IPs or fixed IP ranges at all, so there's no way for you to include this application's IP in an allow list. In order to make that possible, you would need to host your own instance of this application (assuming it is open source) in a Heroku Private Space, which does have specific assigned IPs for network egress, and then allow-list the IPs of that Private Space. Note that Private Spaces come at a substantial additional cost.
I'm quite new to React and after doing a Todo web app I've tried creating my first fullstack web app.
The app sends a request upon entering an Email and pressing a button that should send the users mail to a DB and get his IP which would also be stored into the same DB. This would later be used to check if the user had already done something on the site (After entering the email the client-s sent to the next page) and disallow the user to proceed if either the email or IP are already stored in the DB. What would be the best way to both grab the IP upon entering the email and what would be the best approach in regards of storing it into a DB? (Should I even store it there is there a better alternative).
I'm writing my code with Typescriptx and using Express for my backend & postgres for my DB.
TLDR: How to get the clients IP onClick / upon recieveing a request from them and store it in a database to later compare when the user sends the same request again
On the server side, you can get the IP address from the incoming request. That's the right way to do this (but see below: I think you probably don't want to do this).
In express, this is available via req.socket.remoteAddress. If you're behind some kind of reverse proxy like a CDN then this will give you the CDN's IP, not the real user, but all modern proxies will include the original IP in a request header such as X-Forwarded-For to work around this. You can get the IP from there instead, if that's present. You'll need to look at the docs for your specific infrastructure to check the header they use in this case.
That said, it sounds like you're trying to ensure each user can do exactly one thing, so that after sending an email nothing else is allowed. Is that right?
If that's the case, limiting it by IP address isn't a great solution. Two reasons:
Many users share an IP address, e.g. many many mobile users who are behind CGNAT, everybody sharing an office/home, etc etc
At the same time, many users have multiple IP addresses, e.g. offices that use multiple internet connections in parallel for failover or performance, or people taking their computer from their home to a cafe, etc etc.
In both cases, you'll end up blocking or allowing large numbers of users incorrectly. Typically this kind of thing is done with cookies/local storage on the client side instead, which lets you block this individual user's browser. That will work correctly in environments with shared IPs and environments with multiple IPs.
A client-side approach is not 100% secure, since a technical user could easily clear their cookies to avoid this. If you need a hard guarantee though then neither option would work (it's easy to change your IP too: go sit in the coffee shop outside, or use your phone as a hotspot). In that case, you need to tie the user to something they can't as easily change, maybe an email address, credit card, or even legal ID if you're seriously trying to lock this down hard.
I wouldn't bother: for most web app, client-side storage is usually the right choice.
I develop Google App Engine application and want to provide separate 3rd-level domain for each registered user (e.g. username.example.com).What is the best way to handle such kind of features in App Engine?
Currently I see the only one way - set wildcard DNS A-record CNAME-record to point to the application's main address, handle all requests in the central request handler, then parse request's URL, fetch username from URL, and then apply logic neccessary for specified user. But it looks like error-prone approach since it involves manual work and assumptions.
You can't use an wildcard A record wildcard to point to the app; A records point to a single IP address and App Engine apps don't have a single IP address.
You need to use a wildcard CNAME record pointing to ghs.google.com.
Then, in your application, parse the hostname and act appropriately. I'm not sure what you mean by "manual work and assumptions"; it's fairly trivial to split the hostname on . and lookup whether there's a user registered with the first part of the hostname in your database.
Should I save this information in the database?
For example when users sign up or log in?
Unless you're tracking the users coming to your site, limitting access based on IP address, or providing geographical services (based on IP lookup)...then you don't need to save this information at all.
Rate Limiting (to protect your resources eg. API)
Security (for auditing reasons - match IP with user credentials)
Geolocation based services (if not now, maybe in the future?)
Data for future load-balancing functionality
Some sites, like banks, will use this info as a security measure. If you try to sign in again from another IP address, you will be asked to confirm your identity.
If you were implementing an auto-sign on feature than you are likely to store this (alongside checking for data in a cookie) to attempt to verify that the computer is the correct one for the user, before auto-logging them on.
Most web servers already log this kind of information in their log file.
You may want to log the IP in order to match up the web logs with your user via the IP (and time).
This will not be 100% correct, as IP addresses can be shared (for example behind a NAT firewall).
Should you do this? It depends. Do you need this functionality? Depending on the answer to this question, you should make your decision.
IP bans for misbehavior. About the only solid reason for collecting the raw IP addresses (and not "cooked" data like geolocation or ISP). If you get several similar ban reasons for new accounts, check the IPs they logged in from, and if they are the same or very similar you may want to block on per-IP basis.
You should save IPs of users only when you have a poll or rating system where anyone can vote once. Also you could store IP data to check for multiple log in sessions so people can sign out other active sessions from your site, like in GMail.
We do a site where the "authorities" of our country often call in and what to have IP addresses from a specific user because of copyright infringements or other lawsuit reasons. This might be country specific but for us, this is a reason to keep some IP addresses of our users.
I have set up a custom domain for my google app engine application, which accepts incoming email. While this works great if you want to use an email address like example#example.appspotmail.com, I would like to use a custom domain like example#example.com. Is it possible to do this?
A solution that will not work, is to simply use Google Apps to forward emails to the appspotmail address. This is because I accept emails to any number of email addresses at my domain, and I would need to set up this forwarding for each one - simply not doable.
Thanks for any help!
Devon
App Engine doesn't currently support receiving email on custom domains. You'd need to point your MX records to a service that supports mail redirection, and have it redirect all addresses to your appspotmail subdomain.
If I understand correctly you have many different email addresses you want to forward to appspotmail and due to the large number of addresses it would be time prohibitive to set up forwarding for each one. One solution I admit isn't perfect but works well is to set up a single email account that forwards all email to appspotmail. Then in Google apps make that email address a Catch all email address. What this does is that any email address that does not match an existing email address will go to the catch all email adress then it will be forwarded to appspotmail. With this trick you must only verify a single email address.
It will also allow you to specify a few addresses that don't go to appspotmail by creating the email accounts if you need to. This solution allows you to have an unlimited number of addresses forwarded to appspotmail.
Solution 2 allows a limited number of addresses forwarded to appspotmail. Create an email address that forwards to appspotmail then you can assign that address multiple "nicknames" which are aliases for that account and will also forward. You can create up to 30 email aliases for an individual account. If you need more create another account and repeat. The maximum number of email aliases for your Google Apps account is 10 times the number of user accounts. Using this technique if you have a free account and you signed up after May 10, 2011 you can make up to 310 forwarding addresses. If you have a free account and signed up before May 10, 2011 the limit is 1550 forwarding addresses using this technique.