Is it possible to use SSL one one of the servlet-mappings in web.xml?
I have a site using GWT for browser access and mobile phones accessing the gae via simple HttpServletRequest in servlets.
The setup:
Browser GWT Access
For the site, the user log in via Google Account or Facebook. Then the user interacts with the site - no SSL setup here as I am using Google App Domain.
I guess the communication regarding user and password is safe in this senario with tokens etc. right?
Mobile Access
The user interacts with the Google App Engine(Java) from Mobile phones - the user and password is passed along each call. This I need to be SSL and safe.
I have seen thinks like this: using https sparingly in my GAEJ app
But I am not using RPC from the mobile access.
Any thoughts on this - Thanks in advance
Regards
Therefore I am thinking SSL on the Google Ap Engine, but is it posible in my scenario
Yes, it is possible to use ssl with appengine but you have to use the *.appspot.com domain, not your own domain name.
See the following link for information about securing specific urls in appengine in web.xml
http://code.google.com/appengine/docs/java/config/webxml.html#Secure_URLs
hth
Related
I'm trying to create a web application that uses a Web API to perform database operations. I've created a project at work that uses Windows Authentication on the API Level. Since this is an intranet web application I don't need to implement a login mechanism on the web application. However, this project I'm working on can be private or public web application and I would like to implement a login mechanism but I would like to be able to specify what type of security to use i.e. LDAP, generic username/password, Google, Facebook, etc.
The question is, what is the best strategy to implement security on both Web Application and Web Api. For Web Api, I could probably implement some soft of token mechanism like other Apis. But not sure if there are other ways.
Is Sign-in option like Google, Facebook, etc done on the Front-end side? or can I Implement it on the WebApi side?
The best practice on this case,
Web Application: client certificate authentication or username/password
Web API: JWT
or if the target company uses G suits with the company domain, Google will be okay.
You can set a filter using domain name of the email address.
I am designing a platform for serving media content for media makers, that works with web torrent. But for premium users we want serve high availability of content (for old media, that maybe has not seeds) using http seeds (web seeds) with BEP0019 standard (http://www.getright.com/seedtorrent.html). Obviously premium users needs an authentication method for webseeds. I think that http authentication maybe works for it, but I was researching and I have not found some way to authenticate and secure the http seeds in way that only premium users has access.
Also I don't want overlook that availability must be in browser and torrent client.
Thank you in advance.
Alternatives to basic auth are:
IP whitelisting whenever the user logs into your website. This may be an issue for users that run a torrent client on a server, so you should at least offer a login API that can be curl'd.
embed a login token into the /path/ segment of the URL. but practically that is not much different from basic auth
I'm writing a client in NodeJS that is meant to replace using a website, and it isn't my website. It uses Facebook to log in. Is it possible to log in via a Facebook username/password? It seems modules like passport-facebook are intended for use with a website that you own, which is not the case in my scenario.
I suspect that I can't login with a username and password, so I'd have to sniff web traffic of me browsing the normal website for my token for the website, and then somehow use that in Node, but I hope this isn't the case.
Thanks for your help.
How to obtain oauth access tokens from google if i have only registered app and no server to redirect (as a "redirect_uri" parameter)?
I'm guessing that when you say you have no server, that your app is a native app. eg a desktop app or an embedded app. If so, you can generate tokens using the OAUth playground. See How do I authorise an app (web or installed) without user intervention? (canonical ?) for details.
You can use https://www.example.com/oauth2callback as your redirect uri.
Yes you can get an access token without a server. We've made it fairly easy. See the docs
On android it is fairly easy
https://developers.google.com/identity/sign-in/android/additional-scopes
https://developers.google.com/identity/sign-in/ios/
https://developers.google.com/identity/sign-in/ios/additional-scopes
Web
https://developers.google.com/identity/sign-in/web/incremental-auth
You can just change the scopes you need.
Firebase provides database back-end so that developers can focus on the client side code.
So if someone takes my firebase uri (for example, https://firebaseinstance.firebaseio.com) then develop on it locally.
Then, would they be able to create another app off my Firebase instance, signup and authenticate themselves to read all data of my Firebase app?
#Frank van Puffelen,
You mentioned the phishing attack. There actually is a way to secure for that.
If you login to your googleAPIs API Manager console, you have an option to lock down which HTTP referrer your app will accept request from.
visit https://console.developers.google.com/apis
Go to your firebase project
Go to credentials
Under API keys, select the Browser key associated with your firebase project (should have the same key as the API key you use to initialize your firebase app.)
Under "Accept requests from these HTTP referrers (web sites), simply add the URL of your app.
This should only allow the whitelisted domain to use your app.
This is also described here in the firebase launch-checklist here: https://firebase.google.com/support/guides/launch-checklist
Perhaps the firebase documentation could make this more visible or automatically lock down the domain by default and require users to allow access?
The fact that someone knows your URL is not a security risk.
For example: I have no problem telling you that my bank hosts its web site at bankofamerica.com and it speaks the HTTP protocol there. Unless you also know the credentials I use to access that site, knowing the URL doesn't do you any good.
To secure your data, your database should be protected with:
validation rules that ensure all data adheres to a structure that you want
authorization rules to ensure that each bit of data can only be read and modified by the authorized users
This is all covered in the Firebase documentation on Security & Rules, which I highly recommend.
With these security rules in place, the only way somebody else's app can access the data in your database is if they copy the functionality of your application, have the users sign in to their app instead of yours and sign in/read from/write to your database; essentially a phishing attack. In that case there is no security problem in the database, although it's probably time to get some authorities involved.
Update May 2021: Thanks to the new feature called Firebase App Check, it is now actually possible to limit access to your Realtime Database to only those coming from iOS, Android and Web apps that are registered in your Firebase project.
You'll typically want to combine this with the user authentication based security described above, so that you have another shield against abusive users that do use your app.
By combining App Check with security rules you have both broad protection against abuse, and fine gained control over what data each user can access.
Regarding the Auth white-listing for mobile apps, where the domain name is not applicable, Firebase has
SHA1 fingerprint for Android apps and
App Store ID and Bundle ID and Team ID (if necessary) for your iOS apps
which you will have to configure in the Firebase console.
With this protection, since validation is not just if someone has a valid API key, Auth domain, etc, but also, is it coming from our authorized apps and domain name/HTTP referrer in case of Web.
That said, we don't have to worry if these API keys and other connection params are exposed to others.
For more info, https://firebase.google.com/support/guides/launch-checklist