I am thinking of using another "less" important server to store files that our clients want to upload and handling the data validation, copying, insertion, etc at that end.
I would display the whole upload thingy through iframe on our website and using HTML,PHP,SQL as syntax-languages for the thingy?
Now I would like to ask your opinions is this is a good or bad idea.
I´m figuring out that the pros and cons are:
**Pros:
The other server is "less" valuable, meaning if something malicious could be uploaded there it would not be the end of the world
Since the other server has less events/users/functionality/data it would help to lessen the stress of our main website server
If the less important server goes down the other functionality on main server would still be functioning
Firewall prevents outside traffic (at least to a certain point)
The users need to be logged through the main website
**Cons:
It does not have any CMS+plugins, so it might be more vunerable
It might generate more malicious traffic towards it.
Makes the upkeep of the main website that much more complicated for future developers
Generally I´m not found of the idea that users get to uploading files, but it is not up to me.
Thanks for your input. I´m looking forward to hearing your opinions.
Servers have file quotas and bandwidths defined/allocated for them.
If you transfer your "less" used files to another server ,it will help your main server to improve its performance.
And also there wont be much maintenance headaches with the main server if all files are uploaded there.
Conclusion : It is a good idea.
Well, I guess most importantly, you will need a single sign-on (SSO) solution in place between the two web applications. I assume you don't want user A be able to read or delete files from user B.
SSO between 2 servers is a lot more complicated than for a single web application. Unless this site is only deployed in an intranet with a Active Directory domain controller in which case you can use Kerberos.
I'm not sure it's worth it just for the advantages you name.
Related
I don’t know if I asked my question correctly, but I wanted to know how it’s done. We have a website, and yesterday we noticed that the index.php file was deleted in the server, and instead added the index.html. We know for sure that the problem is not in the server, I mean that they didn't hack the server, and I would like to know with what attacks they could do this. I understand that there can be a lot of options, but I ask for help, can someone describe how this can be done, or give some kind of link where I could read about it. I apologize if I described the situation poorly, but I think someone will understand what I am asking for, and maybe help, thanks in advance.
The main attacks are most likely related to a rootkit, specific modification of a server is hard to do with an automated script, so your suspected hacker is likely accessing your server through a back door; you need to make sure that you are only keeping the needed ports open and have firewalls to detect scanners being used on your server. Another option, if you have the funds, is to store your files in a backend storage server, and allowing your frontend server to access those files, it's not foolproof, but it should effectively square the amount of time to detect an open port and pass through the firewall.
Look into these website(s) if you need more info: https://www.veracode.com/security/rootkit
https://en.wikipedia.org/wiki/Rootkit
I've proof read these, and they work well for some basic elaboration on the subject, as well as some prevention methods.
So I'm currently working as part of a project for a degree course. We have a real client who is having a website developed for them. There are connections to Databases within this site, which are stored in the "appsettings.json" file of the project. This is all local stuff at the moment but will be moving to a live server in the next couple of days.
I am wondering if this JSON file needs to encrypted or abstracted from so that the connection strings, which include the obvious things, IP's, Passwords, Users, can't be accessed by someone attempting to break into the site.
If it does, what is the best practice to go about this?
Cheers
This may not be the quick answer you are probably hoping for, but a better way for your app to receive its database credentials (and indeed all secrets) through environment variables.
It sounds like you are a student. Congrats! Those are fun times. As you gain experience, you'll run into many problems such as this that are best handled by sticking to the 12-factor app guidelines. It would be well worth your time to review those.
I am working on a personal project and I have being considering the security of sensitive data. I want to use API for accessing the Backend and I want to keep the Backend in a different server from the one the user will logon to. This then require a cross domain accessing of data.
Considering that a lot of accessing and transaction will be done, I have the following questions to help guide me in the right path by those who have tried and tested cross domain access. I don't want to assume and implement and run into troubles and redesign when I have launched the service thereby losing sleep. I know there is no right way to do many things in programming but there are so many wrong ways.
How safe is it in handling sensitive data (even with https).
Does it have issues handling a lot of users transactions.
Does it have any downside I not mentioned.
These questions are asked because some post I have read this evening discouraged the use of cross-domain access while some encouraged it. I decided to hear from professionals who have actually used it in a bigger scale.
I am actually building a Mobile App, using Laravel as the backend.
Thanks..
How safe is it in handling sensitive data (even with https).
SSL is generally considered safe (it's used everywhere and is considered the standard). However, it's not any less safe by hitting a different server. The data still has to traverse the pipes and reach its destination which has the same risks regardless of the server.
Does it have issues handling a lot of users transactions.
I don't see why it would. A server is a server. Ultimately, your server's ability to handle volume transactions is going to be based on its power, the efficiency of your code, and your application's ability to scale.
Does it have any downside I not mentioned.
Authentication is the only thing that comes to mind. I'm confused by your question as to how they would log into one but access data from another. It seems that would all just be one application. If you want to revise your question, I'll update my answer.
I want to create a dynamic website that does not support IIS. The area where I work does not allow anything to be installed in the server. The have a windows based server and I would like to create a dynamic website. IIS not allowed and server side languages like asp.net, php are not allowed. They did not say anything about client side. Is it possible to do?
In short, a general answer to your question Is it possible? would be No, it's not. And if you still find a way, it's not going to be worth the effort.
For one thing, even without programming languages like ASP.NET or PHP, you still need a web server such as IIS to serve static content. There are of course alternatives to IIS specifically, but no web server at all means no serving web sites at all.
If you would be given an opportunity to server static content, you could possibly produce a web site that is dynamic at least on a per visit basis using client side scripting and cookies, but the things you could make that site do would be very limited, and without anything other than serving static content there is no saving things between sessions, or in any way affecting the server side of the application.
You have to ask yourself why you need to serve this website. Is this something your company would benefit from? If so, could you convince the IT department to setup an environment to serve it? Are there any other alternatives? And, perhaps the most important one: there are lots of free or almost free web hosting solutions out there. Why not just use one of them?
There are many excellent reasons why you would want to create a dynamic website without using a web server. Here are a couple:
You are creating a website as a means of presenting a dataset with hyperlinks that you want to be able to archive on read-only media and ignore for 10 years or more (as you can do with books), and still be able to read (IIS is very poor at backwards compatibility).
You need to present your data to people who have no access to servers or the internet and have no idea how to turn their PC into a web server (there are many millions of such people in the developing world)
Yes, it's challenging, but if you want something to be readable by anyone, anywhere, anytime, and all you can count on are web browsers, there's no option.
By saying you want to do it without IIS, I'm assuming you're implying Apache as well (since you reference no server-side languages).
It depends what you mean by 'dynamic'. Essentially you'll be limited to
JavasScript, which means that you can manipulate information and elements already on the page.
iFrames - this would let you load external pages into elements and pages on the page. These could be dynamic, and if they were on the same server you could manipulate it as well. If it was from an external server, then you wouldn't have control over it from that page.
If you are able to set up an HTTP proxy, you can use JavaScript together with a service like CouchOne. You will need the proxy, since browsers restrict AJAX calls.
The way we currently manage site roll outs to the server and then switching sites between demo/acc/live "mode" is a bit hap-hazard and i'm looking to improve the whole process.
I've been reviewing automated deployment tools, but also the way the server is structured. I'll save the automated deployment questions for another post, here i'm interested in how people organise code on their production servers.
We currently have 3 top level folders on the data drive, "demo", "acceptance" and "live". There's tenuous differences between what classifies something as "demo" or "acc" which i won't go into, suffice to say i want to be rid of all argument/ambiguity.
Our rollout procedure is as follows, once a site is developed, roll it out under an "acceptance" host header such as acceptance.project-domain.com under the "acceptance" folder. The client reviews the site, we give it a test to make sure all connection strings/permissions etc are correct. The client gives the OK to go live. At this point, we completely re-roll out the site under the "live" folder and give it the live host header. of course at this point the site is totally untested in its deployed state (not talking about unit tests here, i mean file permissions, iis setup mistakes etc). The site then has to be re-tested :(
I think a structure something like this, would be much better:
/<customer>/<project>/<fullversion>/wwwroot
This way, a new site can be rolled out to a version1 folder under an "acc" host header. If the client gives the OK, you simply switch the headers and youre away. If there are change requsts, they go under a v1.1 which can have the acceptance header, once it gets the ok, swap the headers and youre good. Rinse and repeat.
This process would also be much easier to manage for an automated deployment script. Having all the code for a site under a single parent folder means upload permissions can be restricted to a single site, so you cant accidentally overwrite another site's code, its much easier to keep a track of what versions there are on the server, the project management wiki can easily be maintained... the list goes on!
What are your methods of code organisation and rollout management?
Most people don't operate in the way you've proposed because they use separate servers for test and live.
We have stripped all configuration out of our projects, so we can deploy exactly the same code to the test and live machines and they will automatically pick up the correct config. This prevents unexpected "oops I'm pointing at test instead of live" moments.
Your idea may well work - but what if you do decide to split your servers up in the future (you can't exactly run performance testing against it if it could potentially impact your live websites for example).