I am new to wechat development, as I can see from the documentation it requires setting up a server, getting a domain and ssl certificate. I am developing an app that sends a request to a server, fetches pdf file from database and downloads that file to user's phone. Since I am using pdf, I need to store binary data, so VPS hosting should be the best option here. But I am not sure if I can use it for WeChat, I noticed in most documentation and tutorials developers are using cloud services.
Of course.whatever serve provider is.
Related
Question
If InstalledAppFlow requires client secret json file to perform oauth2 authorization, how actual real-life applications using Google API are distributed?
Is client secret json file should be considered as part of application and included as constant?
Context
Currently I am learning how to use oauth2 to authorize google APIs access with python module google_auth_oauthlib.
And I found that Oauth2 authorization process itself require client secret files for InstalledAppFlow authorization method, but I never seen an application that asks for authorization asking for client secret.
After countless searches all I could find about it was this, from google identity docs.
The process results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.)
And from google cloud docs
Save the credentials file to client_secrets.json. This file must be distributed with your app.
Is this explaining that I should embed(include) client secret as constant in the code itself?
The issue with the client id and client secrete is that they need to be kept secure. Googles TOS requires that developers keep their client id and secrete secure
Asking developers to make reasonable efforts to keep their private keys private and not embed them in open source projects.
This can cause issues with for example open source applications. Can I really not ship open source with Client ID?
I have had a few conversations with the Oauth2 team at google over the years. Installed applications those that are compiled anyway can compile the client id and client secrete internally however that would not stop anyone from decompiling the application and retrieving the client id and client secret.
I was told that they are aware of that issue and that there is really no way around it.
I have seen other option where the client id and client secret would be sored on the server and then the installed application would request them from a web api. This is another option but you are sending them across HTTPS it should be considered secure even if you double encrypt them.
The fact of the matter is there really is no way around it. The main thing is that you should not release an application with for example a settings file where the client id and client secrete appear in clear text that would IMO be to great a risk you would need to compile it into your application or at the very least encrypt it some how.
You wont stop someone who really wants to get it from getting it but you will stop most people.
Why installed apps are the issue.
There are serval types of applications. Mobile, web, installed.
With mobile and web there are ways of configuring the client so that you can ensure that they only work form your server. With Web you have a redirect uri, with mobile there is the actual mobile api id.
With installed applications this is not possible because they mostly run on localhost. There is no way for you to know where the app is running so they are left open. So if anyone got ahold of your client id and client secret then they could use it for their app. Users would have no way of knowing it wasn't your official app and neither would google.
As you have a python script why not consider instructing your users in creating their own client id and client secret then they will be independent.
I have a vps, where my spring boot backend is running on. The frontend is a mobile app built with the ionic framework.
The backend is built this way: in the front there is an so called resource server, which is an graphql server, which redirects the requests to rest microservices which are behind the resource server. Every microservice has is own task, which he's responsible for. (e.g. an fileupload-server which uploads/downloads files to a database). The whole application, including the frontend is secured by an keycloak instance, which is running as an docker container like the whole application, except the frontend.
Now my questions is, we dont have a domain and for some reason they wont buy one, but we wont to secure the communications over ssl/lets encrypt. But lets encrypt isn't able to create ssl certificates for ip adresses. So finnaly my question is: do you guys, know a solution to my problem which fits?
So far,
Daniel
I built an app to offer a client of the company I work for that I deployed to Firebase. It uses Firebase storage for retrieving files as well as the realtime database. It's actually just the front-end portion of a two-app suite I made; the backend portion is used by an admin for uploading files, checking data, etc --- which data then becomes available to view over the frontend. Both use firebase.
It turns out the devices that would need to access the app (tablets mostly) are inside of an extranet with a server that can establish VPN connections only. Now I'm being asked how I can build the app so these devices can access the app.
I don't know much about the inner-workings of Firebase but it seems to me I may have couple of options:
1) Figure out how to make the FB database accessible over VPN (preferable)
2) Reconfigure the app to use something like MongoDB. Instead of deploying on a remote server, let the on-site server service the devices using the app. Send files that are needed by the server via FTP over the VPN, then process these files on-site.
Problem: I'm using a Mac and the on-site server uses Windows. It will be a pain to install things on a Windows machine remotely, let alone set up the VPN.
Any ideas? I'm sure there are parts of this question where I've made wrong assumptions --- I've never needed to do things over a VPN before.
I have a server of my own running locally on my wifi, on 0.0.0.0:5000.
I have built an app with the parse.com backend, and I want to link this server to Cloud Code, so I can call functions on it.
I am completely lost and don't know where to start to bring my server online with only Parse being able to access it and use its API.
Or am I better off renting a VPS and connecting to that?
I am working with Windows Azure and am just using the Blob Storage. I have setup my Blob Storage to run in its own Solution file with a dummy web role. I run it first on my development machine so the Azure Services start. I have configured the service to use the development shared key and account name.
I am running into an issue when I point my web application (in another solution) to the local Blob Storage service. I can upload a file to the Blob Storage and I can see the records in my local database. Therefore, I have entered the correct settings in the web.config. However, I cannot access the file via a simple Get request. I have verified that the container is public.
The URI I am using is:
http://127.0.0.1:10000/{container-name}/{filename}.{extension}
My code works when I use my production Azure Services, so is there something different about the Development Environment that I am missing? Does the local environment allow REST access?
UPDATE: I recently found this MSDN Article that describes the differences between production and development Storage URIs. I also documented my environment here on my blog.
The uri looks to be slightly incorrect, the format for the development storage uri is:
http://<local-machine-address>:<port>/<account-name>/<resource-path>
Given that the account name is always devstoreaccount1 your uri should be:
http://127.0.0.1:10000/devstoreaccount1/{container-name}/{filename}.{extension}
What kind of response or error code are you getting?
If you are using IE- you can install Fiddler or use the built in developer tools in IE8 to help debug a communication problem.
Sure- the development fabric works in REST!