I'm looking through the documentation and developer process around developing a Glip app but most of the information seems geared toward the old RingCentral apps. For instance, in the RingCentral blog (https://medium.com/ringcentral-developers/there-and-back-again-a-developer-journey-7180e0faf5e1) I'm told that "you will be unable to make changes to your code and/or API permissions after your application has been granted public access" and I'm wondering how anybody could stop me from making changes to my own web app? This information doesn't seem relevant anymore (admittedly it's an old post but I don't see anything newer).
So, for Glip, the process is to develop in the sandbox, then submit for public or private consumption. What if I want to continue development after submitting a private app, is that allowed? What about a public app? Are there newer resources describing this kind of situation and I'm not seeing them?
Eventually I'd like to have a public app but I'd rather start out with testing on my own private data (live, not sandbox). Then can I graduate to a public app? The sandbox is okay but I don't think I'd want to jump right to a public app without testing it on more relevant data first. I'm not trying to break the rules here, I would just like a better understanding of the process from a web app developer's perspective.
Here are answers for the topics you mentioned:
(1) Changing the App after Graduation
The primary thing that cannot be changed is app permissions. This is necessary because app graduation is based on properly exercising selected APIs and when new APIs are added, the app needs to be tested again. Other things can be changed. This is for both public and private apps.
(2) Graduation Process: Public v. Private Apps
Private apps for your company can be automatically graduated by our automated graduation process. Public apps are reviewed by our team to ensure they are behaving properly before being graduated. You can, and we recommend, testing your app in production after graduation from sandbox, but typically our developers are fixing bugs, not adding permissions for new functionality at that point. For public apps, we also recommend you test with some customers before broadly releasing a public app.
Hope this helps. Let us know if you have any other questions.
Related
I've been working on a django Web app to manage some data for tenants. Things like their personal contact information, government ID, tenancy agreements etc (in other words, very gdpr sensitive info) as well as personally private information such as expense reports. All of this is displayed on the front end of the app as intended seeing as it's supposed to be a private tool for internal company use.
At the moment I run it at home on a local machine server so there is little risk involved however for my convenience I'd like to take the Web app live so I can access it while I'm out and about. The issue I'm having is that there really is no reason for anyone other than myself or business associates to use this app and therefore no reason for anyone else to connect to the domain.
I've considered making the landing page of the website a login page and locking all other views behind this with CSRF protection but even that is too close for comfort in my opinion as it would mean allowing external entities tor connect to the app. I'd much rather have a server which refuses any connection to the outside world straight away unless it is from me. In other words, a server which does not divulge any part of the app or database until login credentials have been correctly entered.
What I envision is that once you type in the domain and hit enter, the moment a connection is made, the server prompts you with an alert box asking for login credentials before any of the app or templates are loaded.
Is this even possible? I've never hosted any of my software online and do not want to fall into a nasty data breach situation by taking this live. At the same time it isn't ideal that the current system operates on the premise that I'm home all the time.
I'm entering the world of Shiny Rstudio now. So this is a beginner question
One question I came up with is: how do I search for the Shiny Apps available/created? Are all created Apps available? Is there any way that, once I create my app, I prevent it from being viewed? Or during the creation I "block it"?
From so much searching I found this link via Rstudio's website: http://www.showmeshiny.com/
Would this be the search platform for all apps made?
But in the case of http://www.showmeshiny.com/ it seems that it is necessary to send it via "Submit App".
I am not sure if I understand your questions correctly but I might be able to give you some insights.
Are all created Apps available?
No, some shiny Apps are hosted on private servers or/and are embedded in password-protected websites or Wordpress-pages for example. If you dont have those access rights, then you cannot see those Apps.
How do I search for the Shiny Apps available/created?
There is no way of doing that, except on pages like Showmeshiny, the RStudio Shiny Gallery, this gallery of recent Shiny-Apps or pther similar pages. Those Apps are publicly available and you can submit your own App if you like sharing it. Shinyapps.io is a nice and easy way of deploying your App on a server with a few clicks. But you need at least the standard license to include authentication, otherwise they would be free and open for everyone.
Is there any way that, once I create my app, I prevent it from being
viewed?
I am not quite sure, what you mean. If it should be blocked from being viewed at all, I dont see the reason of building a ShinyApp. If you just want to access it yourself, then there are ways of doing so. Either password-protect it where only you know the password or host it on a local server that only you can access.
Or during the creation I "block it"?
If you create it on your computer and run it, it will run on your computer and only be accessible to yourself, except you explicitly configure it otherwise. So there is no need of "blocking it".
I am working on a project to create an online medical booking system using Dialogflow as the frontend to provide users with a more personable experience.
So far I have come up with an ideal stack PIC. I plan to have it hosted on AWS (or GCP). However, I am new to Dialogflow but I know it is a very powerful platform. My two criteria are: (A) A stack that makes it easy to personalize frontend UI display and (B) Scalability, I am starting with a web app but would like to also develop an iOS app.
I have two questions: (1) Would you change anything in the stack? and (2) Is there a way to change the name of the bot each time user visits (to make it more "real")?
Super appreciative of you guys expert opinion :)
IMHO, I've found GCP to be easier to use than AWS, since Google handles SSL encryption with .app domains, while AWS requires a more manual solution. Google Cloud also offers a terminal window inside a Chrome tab, which can be a fun experience. So, for hosting, I recommend Google Cloud, unless AWS has a unique feature that applies to your personal circumstances.
Personally, I prefer Angular to React, but Angular, React, and VueJS are all fine choices for a front-end framework on a web app. Your choice of these probably depends on which framework you already know, or (if you plan to outsource development) which language you can use to hire better engineering talent.
For my own projects, I use Express and Node on the server side, instead of GraphQL and Prisma. Your call there.
Good luck!
I've made quite a few web services over the years, and all of them had admin pages, which either could only be accessed by users with proper roles or all together different "admin accounts".
In all the cases, I made some scope in the main project, and made sure non authorized users couldn't access the pages, it works fine.
However I always had the urge to completely part the entire feature into another service, or even create a minimal desktop app that would access restricted APIs.
I know its pretty much pointless overhead to do something like that, but in such instances like having two developers working on the main site and admin site, or security demands that there are to be no browser friendly way to access administrative features, or well just for the sake of it, I was wondering if there are any cases that the administrative pages have been separated from the main web service.
Any examples or design patterns on the subject are welcome.
I'm looking for a "best practice" kind of answer with regard to Facebook Apps and staging/production environment. Instinctively, I've provided each environment with its own Facebook App, complete with its own ID and secret. It appears (here, here and through extensive Googling) that it's simply not possible to share OG configuration across apps, so I've been copying application settings across environments (icon, requested permissions and texts, etc). It's been a pain and ugly, but I've lived with it.
Alas, with the introduction of opengraph actions, this isn't funny anymore - much more to copy and everything has to go through the approval process. Is there no better way to do this? A coworker suggested we simply share the same app across all environments, but I'm apprehensive about that - it means we'll have to share production secrets with the staging environment (I'm not even talking about localhost development environments), and that we'll need to route Facebook traffic to the correct environment somehow (because one Facebook app means one Page Tab URL).
There has to be a better way... no?
I see there's a feature called "Test Apps" now that seems to fit the bill:
https://developers.facebook.com/docs/apps/test-apps/
Test Apps are like regular apps in that they have their own App ID and independent settings, but they offer a number of advantages for use during pre-production:
...
When creating test apps - the settings are copied from your production app so its simple to spinup new apps which mirror your production app's settings
It's working for me so far.
I asked practically the same question at a breakout session at F8 last year. Creating multiple apps is the best practice. They are aware that it is an inconvenience, especially with the open graph objects and actions. They did however mention the possibility of setting up apps in the future via the API, but I am still waiting for this. Until then, it's a manual process.