I'm trying to disable user self-registration in Google Identity Toolkit, or limit the emails that can register comparing them in a database I have. Is it possible? Thanks.
If you want to impose the limitation on the front end, you'd probably have to interact directly with the API (https://developers.google.com/identity/toolkit/web/reference/). If you're using one of the Identity Toolkit libraries, you could also just let people authenticate as normal, but only allow them to complete the registration on your site if the email matches one on the list.
Related
I have a mobile app that does two things. The first one is to use Firebase to implement a chat. On the other side, the apps, uses a REST API to retrieve some info from a database and do some writes on it. Simple as that. The app provides a login system: two text fields and a button. The user provides an email address and a password then I used the standard Firebase function to do the login using signInWithEmailAndPassword(). The thing is that I should use the same credentials to do the login using the REST API to access the other database. At first I decided to do the call to Firebase and to the REST API in the same function. One other possible solution could be a web service. I'll explain how. A web services written in Python, PHP or JavaScript generates a JWT token that is sent to the mobile app after the user asks to sign in. I'm pretty sure that this is possible like shown here: https://firebase.google.com/docs/auth/admin. The latter seems too over-complicated to me. Now, the question is. Can someone suggest a solution, the most simple one, that can be used is a scenario like this? Thanks all in advance.
Woocommerce provides an API here which in order to use it, you have to provide a consumer key and consumer secret with a relevant authorization schema. What I fail to grasp is that, shouldn't be there an API for unauthorized / guest users ? I mean, I just want to create a display page (frontend) of available products, but without the need of generating CK/CS. Also looking in a similar question here
it seems that you cannot avoid using the keys. But a second question comes up. The frontend is not supposed to use the keys, because then the e-shop becomes exposed to the client. So, even by generating these keys in order to access woocommerce api, how am I supposed to correctly use them ? Please help me understand the flow.
TLDR;
Do NOT use CK/CS in front end. It's only for use in a secure backend. The keys can be used to read/write anything from products to, orders to all customer related information.
Based on you questions, I suspect APIs might not be the best way to do what you're intending to do. If you do need APIs, chances are, you have two backend servers communicating with each other. APIs are usually meant for use by other applications. For example, a lot of Point of Sale systems utilize this WooCommerce API. You might want to look into extending the WooCommerce plugin itself and creating end points to get the information or perform actions you need.
If you are not familiar with secure Authenticated APIs, I would highly suggest you familiarize yourself with them as failure to secure the website can result in huge financial losses to sensitive personal information leakage of the site users since WooCommerce APIs, at the time of this writing, only allows you to set read or write permissions with full access to everything.
With that in mind I will attempt to answer all of your questions one by one and give an idea of how you should use it.
To Answer your questions
What I fail to grasp is that, shouldn't be there an API for
unauthorized / guest users ? I mean, I just want to create a display
page (frontend) of available products, but without the need of
generating CK/CS
I'm guessing your misconception is that you need to use separate keys for each user. API keys are not meant to give access for front-end users. The API keys generated by the WooCommerece plugin gives full read/write access to any user to view/modify any information including that of other customers. Its meant for admins. If you check the official WooCommerce API reference for retrieving a customer you'll notice that you get to provide an id here. And if you check the response it shows everything from addresses to contact information.
The frontend is not supposed to use the keys, because then the e-shop
becomes exposed to the client. So, even by generating these keys in
order to access woocommerce api, how am I supposed to correctly use
them ?
Its quite simple actually. You just need to get between the communication between the front-end users and the WooCommerce API. If the users needs to be provided information from the WooCommerce end point, you need to get it for them using the CK/CS.
This way, you confirm what information is allowed to view/modify by whom, and the user does not need to be authenticated.
WooCommerce Endpoints <---> Your secure backend service/middleware/controller <---> front-end user
One thing to note though, is that you need to be careful about the parameters a front-end user is able to change in the request to your server end-point that is consuming the WooCommerce API key. A customer should not be able to change the id that is requesting their info for example. Id should be retrieved from the backend from the secure authentication information coming from the front-end.
Alright, A friend and I are developing an App where I'm developing the back-end and he is developing the front-end. The project is separated into two repositories the front-end and the back-end, and we need to implement a payment API.
Now, since we're using the REST API Concept, we communicate both ends through JSON data.
My question is, when we're making the connection to the payment API, who needs to execute that request? The front-end or the back-end?
I know it's a silly question, but first timer here.
The backend will obviously process the payment, I'm not sure which payment API you're going to use. But depending on the API you go with, the implementation will vary. But the actual processing of the payment will be processed in the backend for sure.
It completely depends on the API.
In some cases, a payment can be accomplished via a secure web service call, which would be issued by your friend's REST service. The front end will still need to collect data (e.g. payment amount and card number) and may also need to collect additional information to satisfy the API (e.g. IP address or browser signature, for risk management purposes).
In other cases, the payment is sent directly to the service from the browser. The role of your application would be to render an iFrame housing a page that is reached via SSO. The back end may need to call a service to retrieve an SSO token, or may have to compute an SSO token using a shared key.
You should probably refer to the payment API's documentation. They often have very specific guidance which you must follow carefully in order to achieve payment card (PCI-DSS) compliance. There is nothing special about "payments" that says that allows StackOverflow users to guess anything about its API.
I am developing a WP plugin that will allow Paypal payments and invoicing. This plugin will allow users to use their own Paypal accounts when accepting payments.
What I understand so far is I need to use REST to enable the Invoicing API. So it leaves me with two options:
Let the users create their own app and enter the client id and secret key into the plugin settings.
Use my own app that I created (only for this purpose) and go with Third Party Payment instead: http://paypal.github.io/PayPal-PHP-SDK/sample/doc/payments/CreateThirdPartyPayment.html
My concern for the first one is that by saving the keys in the database and their site gets compromised somehow - the hackers can execute the API on behalf of their app.
The second one will show the secret keys on the plugin file itself - but then again since the app will only used for this purpose and the Payee/Merchant will only be specified in the plugin settings I guess this is okay? Another advantage would be the user not needing to create their own app.
Which one is better of the two or maybe you can recommend a third option?
Thanks!
Well, you can always generate dynamic payment buttons (similar to what the wizard in paypal does) based on the parameters your user inputs in your plugin and use the express checkout endpoint.But you'll lose some features (like complete customization of the checkout process)
Store the API keys in your database but salt and hash them because they are passwords. Since you are using a third-party CMS, you should assume that sooner or later it is going to have a zero-day exploit and, sooner or later, you will have a hacker with root access to your CMS admin. Design your database and plugins with this fact in mind.
I have two asp.net projects at the different domains. These projects use one database.
Let say www.test1.com and www.test2.com. (Late will be more projects)
I already have registration form and registered users.
Now I need to implement SSO possibility without registration at the external sites (google, openId, facebook).
All implementation which I have found required external registration (CAS, Federation, Facebook, openId).
Also I have read this article http://www.codeproject.com/KB/aspnet/CrossDomainSSOExample.aspx, but as far as I understood from comments such solution very insecure.
Please suggest solution or existed library which can help me to use SSO without external registration.
I needed the exact same solution for a client I was working for, I did the research and the only good solutions that I found where either too complex and not well documented or too expensive (I forgot which companies I looked into). So I decided to build a custom solution.
This is a short summary of the solution implemented:
In order to make things more clear let's call "nodes" the domains where you wanted to authenticate a user, and "SSO" the provider of the authentication.
I used a solution that is similar to the one in the link you posted HOWEVER I used the Asp.Net security cookie whenever I wanted to authenticate a node, and also to authenticate the SSO website:
HttpCookie formsCookie = FormsAuthentication.GetAuthCookie(userName, false, HttpRuntime.AppDomainAppVirtualPath);
HttpContext.Current.Response.Cookies.Add(formsCookie);
This also allowed me to not have to query back the SSO provider for each web request as the example you posted seem to do.
I used a new AuthenticationKey for each time I wanted to communicate from the SSO provider back to the node that the authentication was successfull.
Also I added some security features like encrypted communication and that the key could only be valid a max of 2 seconds (the time for the SSO to pass it to the node) and as soon as it was used it would be deleted.
I believe this solution is safe enough, however using an external ready made solution is surely safer.
It took me only a few days to implement the whole solution, so it's not too long of a task. However I cannot share the project as I am not sure the client would agree.
I hope those suggestions might help you.
Let us know what you decide to do in the end.