I'm junior dev with little experience. I have a portfolio website with some examples of my work. As with many web applications, there's a login. I want to be able to publish the login credentials but have the database reset every half an hour if it's changed. This is to roll back the changes the user has made. As soon as I've published the credentials it maybe abused. The web app is written in php using Symfony
Am too sure how I should go about doing this?
Related
I have a small Discord.js reactions bot that gives roles to the members. It runs fine for 24 hours then it stops... if I refresh the bot with a code it starts working again.
It’s very annoying as I want it to run all the time and not require me to log on every day to manually refresh it.
It is hosted with Heroku if that helps.
Heroku dynos restart one or few times in a day, that's how Heroku's free hosting works. If you lose your reactions use Data base as jonrsharpe said. The easiest to use is MongoDB and there is a lot of tutorials on how to make a reaction role system with it, hope my answer helped!
I have published some Tableau extracts which are pulled from Microsoft SQL server. The extracts are very large, and are scheduled for early in the morning only once a month. I would like to prevent anyone from accidentally refreshing these, even Site Administrator.
When I publish the Data Source, it says I need to embed the authorization for refreshing on a schedule. However now when I've embedded the credentials, any site admins can still select refresh. Is there any way to take that option away, and only allow Server Admins to manually refresh the data?
Say I have 10K users for my app and I want to switch to my own custom server for backend. I have seen the Parse export functionality but I don't get how it can help me in this situation.
I mean even if I export all data and make updates to app so that it makes calls to my new custom server, still, it will take months for all my users to use updated version of app(many users don't update immediately, my last update on fb was year ago).
Also, during this transition half of my users would be having their
data on my custom server and other half(those who haven't updated)
would be using parse server, so for queries that require all data in one place this becomes an issue (I could solve this via replication but imagine how slow it would be in realtime to push the data to both - my server and parse.com).
Has anyone thought about this ?
What you could do is when you release a new version of your app, when a user logs in and they are on parse, migrate their data at that point to the new server and from that point on that user uses the custom server. That way users move to the new server as they upgrade, I always have a flag that is fetched from my server to force the user to upgrade if is needed. Hope that helps.
Copying data over to your new backend periodically until you have finalize your mobile client code and then allow the user to update their app on the App Store or Google Play Store would provide the switch over. Doing that elegantly would be dependent on the type of app and user base you have for the app. I wrote up a part 1 of a blog on these considerations for migrating over from Parse to Couchbase Mobile stack and the reasons why to consider the stack.
If you can already attach a new system in place to have new data in two places (Parse and customer backend) then the copy and merge in the future might be easier to handle but this is case by case. Then when on mobile app update, you can depreciate the server. Or push data to have local store for those users who will be on older versions since Parse will eventually stop working. Any new experiences will require update to the new App version.
I have a business LS web application which I update from time to time.
I do the update by simply using the deploy wizard and everything is working great.
My problem is handling all my users that opened my system in their IE and left it open through my deploy process.
Since they have the old web application is opened on their browsers, and I have deployed the new version to the server, I can see errors occuring in certain situations.
Is there a way to make sure all users with the application opened will be forced to refresh the web application page? Maybe remotely disconnect all currently connected users?
There is no built in way of doing this. You will need to write a custom solution. Someone in the MSDN Forums has written a class to do this for OOB apps.
You should be able to reuse the timer part of that class. I'm not sure if the UpdateAvailable method will work for Web-based applications or not. You'll have to experiment with that.
Alternatively, you can create a custom notification system. Insert a message to your users into a table in your database from the administrator account. Have a timer on the user account check the table every so often. If it finds a new message, display a notification to the user.
Then you can use either an HTTP Response Header or an ASP method to log the users out as described in this Microsoft Support article.
I have implemented Continuous Integration using TFS Version Control and TFS Build 2010. The compiled website project gets dropped in a shared folder with a version number.
Now I have a very basic question and may be a stupid question. When we normally deploy a website project from VS 2010 to a webserver it uploads App_Offline.htm file to the website folder so no requests are served to the user. After publish is completed that App_Offline.htm file is removed. During that period of time users see outage.
If we use CI on a live website then how can we eliminate that outage which appears to a user. I believe the whole point of CI is that users get to see newer features and the site is never down.
How is this accomplished? If we deploy website project to root folder then existing users will be affected and that is certainly no advisable.
I wanted to know what is the recommended practice with VS2010, TFS2010 Build & Version Control.
There's no real foolproof method for this, service up-time is never 100%, that's why people usually define it in 'nines'
But, if you had multiple web servers (Backup, fail-over, mirror etc.), you could roll out the update across them, so that as you update some servers, others will still be online (albeit with the old version) to serve users.
In general, only some of the largest websites have to worry so meticulously about being down for a few short minutes, so make sure you're focusing your energy in the right place ; )
Regarding taking down the site for the shortest time possible, the only way I've seen this done successfully is using multiple sites - either load balancing, or 2 sites on the same machine + swapping host headers after the release/warm up. But in most cases it's not worth the effort, releases shouldn't take down the site for more than a few seconds in which time there should be relatively few requests. You're better off trying a few things you can do to help your users live through a site release.
Move session out of proc.
If the users session lives in the app pool it will be lost when a new version is released, change the config to move it into a session server or the database.
Specify a machine key for the website
Viewstate (and cookies?) are encrypted using a key that is generated when a site starts, if a site restarts due to a release any users filling out a form will receive a invalid viewstate exception on postback. (Note: this may have other security implications)