I've got a Meteor app hosted on Modulus. The app is an in-house app used by a few higher-ups in the company. We're giving it a first trial run. After deploying the app and the db to Modulus, I'm finding the data is reloading about every 10 seconds. It's like the data is reloading into minimongo, so same data appears to flash on and off. It doesn't do this running the app locally.
Insecure has been removed, but I left auto-publish in Meteor because the app needs the whole database to work with. I figured I could remove it and then publish and subscribe the whole database, but I thought that would be redundant. Could this be the problem?
I'm in contact the the Modulus folks about it, but I think they're scratching their heads. I've tried hosting the db on Compose as well with the same result. Something in the app is causing it. Was wondering if anyone might have a suggestion.
Autopublish is the culprit here. Try removing autopublish and convert your data access to publish and subscribe.
If you have already built the entire app, you will have to refactor the entire app as Thai Tran mentioned in the comments.
Also, even if you have every security in place where users are locked up, autopublish still messes your app's security up. Your entire database is on the browser. Even if you have users or not. (Not a best practice in a production app).
Meteor gives autopublish only for prototypes, not production apps.
Anyways, explanation here is with autopublish on there will be lot of Tracker incomputations which might cause these errors.
Remove it and your app should be fine (Of course after you refractor your app to use publish + subscribe).
Good Luck!
Related
I have a Firestore collection that I need to rename.
To do that I'll have to do two things. One, rename the collection, two, update my app (only web right now) to use the new collection name.
My problem is that if I just go ahead and do that, any user that has not refreshed the app won't be able to find the renamed collection.
So, my question is: Is there any best practice to handle this scenario?
I can think of a couple of options:
Somehow forcing a reload of the web apps immediately after renaming the collection.
Set a feature flag so that the web apps enter into maintenance mode while I update everything and then reload the web apps once the change is finished. Unfortunately the currently deployed web app doesn't have a maintenance mode to enable so this doesn't seem to be a valid solution.
However, I'd like to hear about other options. There might be some best practice that I'm missing. Moreover, I'm aware this is a problem that might be more general than just related to Firestore. For example when changing a REST API endpoint, so I guess there must be some tried and tested solutions out there.
I tried searching for best practices regarding this and couldn't find any.
Also, if I was consuming a REST API it would be easier to solve because I could change the DB and keep the DB unchanged. But given that Firestore gets consumed directly from the web app I don't have this benefit.
Locking out outdated clients is a common practice, but leads to a lesser user experience. It also requires that you have a mechanism for the clients to detect that they're outdated, which you don't seem to have.
The most common practice I know of is to perform dual writes to both the old and the new collection while clients are updating.
I see this question has already been asked but not all that recently so I am bringing it up again.
How do you hide your firebaseConfig file, or any secret key, in an expo application? (For production, not dev).
As far as I can tell, there is no way to properly hide the firebase config file with API keys etc in a react-native expo app.
Being that I have already built my entire app around interacting with firestore, I am a bit perplexed as to how to proceed forward.
If I eject, is there a way to properly hide my API key in a non-expo react-native-app? Or will I still face the same problem? Everything is working smoothly and I would prefer not to eject.
I have some experience using node.js/express.js as a backend (only ever in a development setting). Should I build myself a server and then serve the config info from there?
If I want to deploy a 'demo' app, is there a way to hide the keys while still using expo?
Any insight into this would be so helpful.
As far as I am aware there is no 'dotenv' package compatible with expo.
Also I have zero experience in deploying mobile apps, and very little in deploying web apps. I have not yet had to deal with securing keys in deployment.
Any help would be so appreciated.
It's not possible to effectively hide your Firebase config information. The best you can do is make it more difficult for someone to find them. Since all the JavaScript code is running on a computer or device that you don't control, you can't ensure that any of it is hidden from view.
In fact, you don't need to hide any of that. I suggest reading this: Is it safe to expose Firebase apiKey to the public?
If you're using Realtime Database, Firestore, or Cloud Storage, you should be using security rules to protect data so that only authorized users can access it.
I'm really keen to use the 2sxc environment on my website for a number of applications.
I'm currently looking at the Mobius forms.
What I'm wanting to do is create a ticket in ConnectWise rather than send an email, using the ConnectWise REST API.
Some of these questions might have obvious answers to someone who has been taught in these technologies, but I'm self-taught. When I went to school I learnt COBOL!
There is c# code in the application, but I can't see how you build and incorporate into the application. I forked the code and it seems to just code with no build.
There are live and staging folders with the same cshtml files. However, it seems a bit random when the live or staging is actually used. For example, I did a quick fix to the _Contact Form.cshtml so to fix the type that meant it always displayed the ReCaptcha warning, and I changed the live version, which didn't do anything, so I had to change the staging version.
I need to update the settings so that configure the ConnectWise API settings, I haven't been able to find where I can do this? I am still looking though.
I also need to store a private key in the settings. Is there a secure way I can do this?
PS. When I get my head around all this I'm happy to be a contributor
welcome to StackOverflow.
I'll try to give you some guidance to help you figure it out
Live and staging are folders meant to let you make changes while the users see the unmodified output. So a host-user sees the files from staging, others see what's in live. When you're done and all is tested, you copy from staging to live. This we call Polymorphism.
Polymorphism applies to both the cshtml as well as the api. So as a host-user, you'll be using staging/api/FormController to save/send.
There is no build process, everything is hot-compiled. That's one of the things that makes 2sxc so amazing. No Visual Studio, DLL or restarting the application ;) You'll love it.
Secure keys: there is no special secure key storage. We usually put it in the App-Settings, just like the MailChimp key you'll see there. We split it into two fields for very technical reasons, because we publish our code on github and that causes trouble when our code has API keys. But you can just use one field, assuming you don't plan on publishing the code on github.
We had a horror story back in August where our Here Maps SDK License Key was mistakenly changed on us (to this day, nobody still knows who did it and why). It was a nightmare, because all our users' apps froze upon launch and we had to push an update to the app store (and although I've had Apple approve an app update in the past in as little as 4 hours, that time it took them 4 days!!!).
It would make much more sense to store the values locally and then have the info populated into the app. Problem is that Here Maps requires the info in App Delegate which is the top level of app and it's difficult to build database queries in there.
Our license will be renewing soon, so I am thinking of solving this issue once and for all. Anybody had this issue before and has any ideas?
We believe it would be the correct solutions to avoid major incidents.Maintaining credentials in more controlled DB is a right approach instead of keeping in AppDelegates.
For example, say I am working on a FAQ page locally. I create whatever plugins/templates etc I need. Then, locally, I proceed to add the plugins to the page, debug, modify whatever. Now it comes time for me to deploy this to production.
I am left with redoing all the work again, copy/pasting the content and rebuilding the FAQ page or is there an alternative way? Things I have thought of:
Create a data migration representing the structure/content
Sync the production db to the dev db, make my changes and push it all back during a downtime window.
Are there any other solutions around in the Django CMS community for handling this kind of thing?
The data migration seems like the best approach, but I figured I would ask to be sure I wasn't missing anything.
I am not aware of any out-of-the-box solution to this problem. Data migration seems fine, though if you are planning to integrate it into the actual migrations framework, I would be worried about making it too coupled to the state of the database (i.e. if you are inserting the content into a specific page ID).
What we have been doing in our projects is to create as special app that provides additional commands for the management CLI. You can then keep the migrations separate from data population. Once you deploy your plugin structure live, you can simply run a command to populate the database.
After you have seeded the data, you can simply disable / completely remove the temporary app without having any effect on your main application - compared to keeping tightly coupled data population in the migrations framework, that wastes both space and tightly couples the db migration to your db contents.