Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Recently I did some web design work for a person. I continued to show him progress by giving him a link to his new site on my development server. Nearing the end of completion, he dropped all contact with me and I was completely unable to get a hold of him. I took a look at his site recently, and he mixed a combination of his old site, with the new one I was creating. I thought maybe he redesigned it himself after looking at my version, however a quick look at his source code shows that the parts I recognized were full out just copied by viewing the source code on my dev server. So he completely stiffed me and I received no payment from him.
Just wondering if there's anyway to prevent that in the future?
My first thought was obfuscation, but a quick search shows that doing that to html is not recommended and not foolproof anyway.
Obviously this is a lesson learned for me to get some sort of up front payment first, but being able to prevent work from being so easily stolen in the future would be nice.
Are there any developers that have come across similar issues? How do you show someone the progress of your work without giving them plain as day access to your source?
The other answers here are just a set of hacks that can be undone.
The client side, HTML, CSS, and JS is made up of all open source technologies. While you could spend a lot of time trying to obfuscate your client side code, your best bet is just to practice better business logic.
The options open up widely on protections for server side code but your question seems to focus on client side code.
For well established trustworthy clients I am much more flexible but new clients I am super careful with. I demand progressive payments. For each deliverable there is a payment involved. That way if the relationship is ever severed both parties have what they want.
When you make yourself an easy mark for scammers you only attract scammers.
IMHO a good way would be presentations e.g. with TeamViewer or a similar software when you cannot go to your customer.
You could also provide screenshots or a basic remote access with vnc or so, where you customer can see but not touch the site.
What you could do, is use HTML Image Maps with screenshots to create a basic, interactive version of the final product.
It's possible to encrypt your source code with javascript. Try this website: http://www.iwebtool.com/html_encrypter
I never used this tool myself and I don't know if everything works well, but I think it's worth giving a shot. You can always upload the normal source code after being paid. Also, make sure that you have the right contact information of your client in the future. I also highly recommend using a contract in the future so that your client is legally bonded to pay you. Another possible option is giving your client nothing but a screenshot of the site, but of course your site will become static.
Use a website that have an escrow service, or an escrow-like service, where the employer pays all the money upfront to the website, and it will only be released to the coder after achieving a predefined goal.
Many freelancing websites provides this service.
I've built a tool, which really encrypts your JS-sources - no simple obscurity by obfuscation, but good security by encryption.
See how it works here: http://ec2-176-34-64-10.eu-west-1.compute.amazonaws.com/nopro/xscroll - it's a demo only for hiding the script xscroll.js.
When you inspect the DOM in your client, all you see is: nplreq(url) for each script you bind into HTML head.
Encryption and decryption are totally transparent to the browser. It is tested with Firefox, Chrome, Opera, Konqueror, IE8-10, Dolphin and Safari on an Android tablet.
Encryption with AES (Rijndael 256) using one-shot-keys which are negotiated between client and (liblock-)server using Diffie-Hellman.
The sources are securely hidden, and only with really great efforts they may be reached again.
You could either just run the site on your laptop or put the entire site behind a login page that requires a password. You would be able to do live demos, but the client would not have access to the site until you have been paid.
Related
I have taught myself HTML/CSS and some JavaScript as a hobby, and have reached the point where I am comfortable building a clean simple website. The company I work for (we do nothing related to coding) has a website that is quite outdated so naturally I saw this as an opportunity for my first live site. I approached my Managers at work to take a look at my first mock up and they loved it and want me to revamp our current site.
The one concern they have with me being a rookie is the issue of web security. Essentially they want to make sure that the website I build leaves no vulnerability for someone to hack through our server, start editing our website, etc.
There are no interactive components to the current website. I plan to build this website with only HTML and CSS, and perhaps add some JavaScript later down the road once I progress in my learning a bit more. There are no account logins or areas to enter personal information anywhere on the site.
My question comes down to this -- what can I do to ensure that the website I build is not leaving our company vulnerable? I have done a lot of searching around Stack Overflow and other websites but I am not confident I am finding the correct information.
Details that might make a difference:
Our company website is hosted through godaddy.com
Our website is currently on Wordpress, but I will probably not use Wordpress for the new website
I greatly appreciate all of your help!
since there should be no direct interacting with the server ex PHP and AJAX only HTML CSS and js there should be no security issue, as js and HTML can't edit/delete/read server files, only server-side programming can. eventually you may want to invest in PHP almost no website is complete without PHP or AJAX. take me for example, I used to use just HTML, CSS, and js. then I wanted to do more.. log form answers to a file, show different pages based on the query string. these things are virtually impossible in a HTML, CSS, and js only environment. I would also recommend atleast getting free protection from cloud flare.. they give free shared hosting wildcard SSL, and free DDOS protection, granted for a business you might want to invest a little more than free but free would be a good starting point
also you could pay someone to test the vulnerability of your company, take for example OurMine. a legal hacking group.. you pay them to test your security and they do just that. (they claim they don't log anything that they get) otherwise there might be vulnerabilities you may not be aware of
When you are concerning about just AJAX call, I would help you out for following suggestion regarding "Function access rule from AJAX".
By adding "_" as a prefix for Function name, we can prevent function to be called from The Web publicly. This is the best practice when we need some specific function to be accessed via AJAX only.
Kindly, refer my answer given in other question.
[Website Security: How to learn?
A passionate discussion from today.
Developer 1: "AJAX is a set of tools,
use it where it really helps, not just
for the sake of it."
Developer 2: "Its almost 2011, we can
build rich desktop like applications
in the browser, we should use AJAX
everywhere and make a single page
application with everything in it an
AJAX powered component."
I can understand things so far. Here's where I don't get it.
Developer 1: "Using AJAX to make a
single page app, we will have to write
our own code to manage bookmarking and
browser back forward buttons"
Developer 2: "No problem, that's
easily doable. It's worth it because
AJAX solves the problems we had with
normal GET/POST, the statelessness.
With a one page AJAX app, you can
maintain context, you don't need
hidden variables, heavy session
management as you would when you moved
between pages"
Is Dev 2 right? Has AJAX really solved problems with how the 'web' normally works?
No.
First of all, there's no problem with how the Web works. It was designed to be stateless, and even with a single page AJAX app, the Web is still stateless.
The problem is with how Developers approach managing state in the stateless environment of the web. Single page AJAX applications definitely make managing state much easier for developers (actually, it sidesteps the problem entirely) that are used to being able to manage state easily in a desktop application.
Just remember, though, that if you have a single page AJAX application and you forget to send the state back to the server for persistence, you lose it...
In my personal opinion, single page AJAX applications also have code management/readability/maintainability issues that far outweigh the state management benefits. I'd rather learn how to properly pass state from page to page in my application that deal with the headache of a single page that contains all of my code.
You answered your own question with: "AJAX is a set of tools, use it where it really helps"
AJAX has solved a lot of problems by streamlining user experience and allowing the developer to control the flow server-side and client-side scripting. There is a development cost to utilizing AJAX to its maximum potential that its viability is dependent on the project, requirements, performance expectations, etc.
Node.js is very likely to revolutionize web development and web scripting as well. If there is a long-term scope to web development projects, keep the cost-benefits of upgrading to future technologies in mind as well.
There is a time and place for everything. Writing web pages to not load a new page AT ALL 90% of the time is not appropriate. Certainly there are exceptions for web applications such as Google Docs etc... but AJAX solves a need, and that is "I only want to update a small portion of my page, I don't need to load the entire page again."
You have to understand the needs of your users with the realization of expectations. If I make a comment, I do not really expect the entire page to load again. It's not necessary. If I want to visit another article on the page then I would expect it to go to a different page entirely.
Do not think of AJAX as an all or nothing solution. It fits specific needs just like traditional web pages do, and the two can be married to perfection if that is understood. Otherwise you end up having to write code for a solution to a problem that does not normally exist.
This question is for web developers and architects.
How do you think is it a good or bad idea to have a website where you're able to edit all the templates (HTML, CSS, JS, images..) right from the admin panel?
In this case if you update website often, you don't need to search for a local version of your website on you development machine, search for a specific page, make modifications, commit it to source control server, make deployment.. Instead, all you need is just right click on the page or any element on this page, click Edit, update a piece of HTML and click SAVE - 30 seconds maximum - all from your browser ;)
You still can have version control system with this approach and rollback any template which was modified by mistake by 2 mouse clicks on a website.
I personally like this approach and need to know your opinion. So what do you think?
Note, we are talking about big websites which have to be updated often, multilingual ones etc.
Realworld web-applications which use this approach:
Wordpress
vBulletin
Personally, I think it would depend on the complexity of the website.
What you're talking about here is directly editing the structure (and potentially behaviour) of a live website. Sure, it may take longer to make the changes on your development server before rolling them out but if there's any chance of breaking either the appearance or functionality of the site then I'd think definitely think twice.
You shouldn't be allowed to modify the entire layout of your site through the site itself in my opinion. The reasons being the lack of version control and the inability to preview what you are doing, which translate into the inability to come back to an older version. Plus if you modify it locally, you are allowed to make errors that break everything, a luxury you can't always afford if you're doing it directly through the website.
Being able to add/remove content through the website is great though, it would be very painful to update a blog by modifying your HTML each time!
I once created a site that did exactly that. (Well, without any option for source control - had to learn that one the hard way...) Looking back at what I did there, a few things come to mind:
It was a traditional website with information about my sports club, that only changed occasionally, not a web app in the modern sense.
I wanted to be able to apply fixes even though I had no access to my dev machine (because it was a private project, I was at work, and ftp connections were not allowed by the comapny proxy).
For those specific reasons, the approach was a good solution. Today I would use one of the many good frameworks for this purpose (Joomla, Drupal etc) instead of coding it myself.
On important item: I was able to edit the pages that were used to generate the main site, but not the generation program or my admin pages. For those, I had to use my dev machine and upload file changes by ftp.
I think it is a good approach, if done correctly (my implementation certainly wasn't)
Editing HTML/CSS/JS files through your web browser can make things easier, as long as the editing implementation is neat, organized, idiot-proof, and keeps track of revisions.
A major issue to consider is security. The inability to modify actual files from the content management system in most software packages is a security precaution.
Learn to use a version control system effectively and efficiently. Tools like git or bzr can take care of a lot of the tedious stuff automatically, like package building, uploading, etc.
I hate it. Web development, much like the web servers themselves, shouldn't be "comfortable". Web development should be a mother gentle caressing scary experience. It should sound, look, even taste dangerous.
Neophyte web developers should be put through their paces learning the subtler aspects of their chosen text editor before they are even allowed to open a web browser; and not be allowed near a graphical web browser before 6 months of working only using lynx for debugging.
Laziness is our bane. No more, I say.
Edit: This is, perhaps, a bit tangential to the issue at hand. It should also be mentioned that visual identity that is too simple to change will change too often, leading to confused and frustrated users.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Is it risky to have dependency on a open source service?
Unlike a open source dll or componenent the service obviously needs to be constantly running, therefore is it a business risk to rely on it? What happens if the open source service disappears for whatever reason?
The service under question would not be used for a business critical application but if successfull it will obviously gain in importance?
Many Thanks
If it's really "Open Source" (as opposed to merely free), you can download the source and run it yourself it the original provider goes away. Of course, you'd want to download the source ahead of time, because if the service provider goes away, there's not guarantee that there will be a site to download it from. Also, you'd probably want to keep backups of the data for yourself if you can.
But if you're misusing the term "open source" to mean a free service like the Google Maps API, then yeah, if it goes away, you're boned. But if Google Maps goes away, so is half the net.
What exactly is an "open source service"?
Any old website that offers an API? Yup, depending on it is a risk - they could go under or start charging a fee
Or a site that publishes the software it's running under an open source license? Just download a copy and if the site goes away, you always have the option to run it yourself
The better question is this:
What happens if your paid enterprise you rely on goes under, and you're left without any code whatsoever, and no support?
With that in retrospect, Open-source guarantees a future. All you have to do is find somebody to hack it. Proprietary on the other hand, legal hilarity ensues.
IMHO, the same as a closed source service.
Both, usually, have the same chances of being closed, with the usual surprises of course, as also Google and Microsoft close services without any previous notice.
Same as Paul says, you can run that service if it gets very important, if it closes, or you need big things of it.
But most important thing, appart from being open or closed source, is the access to your data... in case the service closes or you need to move away... will you have access to all your raw data for moving?
Probably yes. But if it is not a mission critical application, it might be okay.
I personally would try to avoid it just because of its vague future. But you never really know whether a commercial service will live through next year.
Just don't bind tightly to this service and not design strictly for it. Design so as to facilitate switch to another similar service in the future or even to a very different approach.
Design for the family of similar services. And always think of an escape plan in case this service goes away or even all services of the class.
I've also had similar considerations about this service: http://www.webservicex.net
Seems to be freely accessible but who really runs it and who can guarantee it will be there tomorrow?
As for tomorrow, even Google Mail happens to be down at some days. What do you want then of a free open-source service? :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Say I had an open-source project which I wanted to try and generate some exposure for. Would it be considered unethical to set up a project entry for it on several sites such at github, sourceforge and google code, for example?
This would be purely for giving it greater exposure. I realise there might be some practical reasons for doing this, such as wanting to use github for source control, and sourceforge for issue tracking, forums and such. For the sake if this question I'm wanting to focus more on the case where you use one of the sites as the main site for the project, and make "stub" projects on the other sites that point back to the main site.
My gut feeling is that while it may not be outrightly unethical, it might be bordering on the sleezy side...
Stick with one provider. "If you build it, they will come" :)
Besides, once people do start coming, they'll just google the project name anyway. Finding the same project on Sourceforge, Github and Google Code is just going to annoy the hell out of people.
I don't know about the ethics, but consider the practicalities:
you will have to do multiple repeated
uploads to several different sites,
doing it to a single site can be a
pain
users won't know which site to report
bugs at
if you use the SVN/CVS/git
repositories, you will have multiple
copies of your code in different
repositories - a very bad idea
I'm sure there are other problems. So stick to one site - I've been using Google Code for a small project I've just started (CSVfix, if anyone is interesed) and I can recommend Google as being very easy to set up.
I think this is fine, for the reason that each provider may have something you want. You should pick the services that are best for your project. For example:
Google code has file hosting, but the issue management is terrible, so
Launchpad has great bug tracking, but no wiki, and we use Mercurial, so
Bitbucket.org has mercurial hosting etc..
So it might be reasonable to use Launchpad for bug tracking, and Google code for hosting files and wiki, and Bitbucket.org for hosting source.
I would suggest choose your preferred host for your project. You can publish about your project on many forums. Exposure will come via search engines.
I don't know why you think it would be unethical or sleezy. Maybe you can say more about that so people could address your concerns directly. To measure that, consider if you are intentionally breaking the rules of the service, lying to anyone about how you are using the service, and being deceptive in some other way. If you are using multiple services, I don't think you have anything to hide.
Consider the Perl community, which is the one I deal with. Several projects are hosted on one of the source control services, such as SourceForge, Google Code, or Github. The main distribution for most Perl stuff is CPAN, though. Other people may distribute through Freshmeat or some other service. The main issue tracker comes from Best Practical, which hosts a free RT for every Perl module on CPAN. Most of the people I know use the best from more than one service. Indeed, the Web 2.0 way is to create applications by cobbling together services from multiple vendors. :)
You should also think about the social construction of these free sites. Places like SourceForge and Github give out free accounts, but they also sell services. They get the buzz through the free stuff that allows them to sell the premium services. I don't see anything wrong with that. If you're using the free services, just realize that in return for your free use, they get to use you as free tester, advertiser, and so on. Again, I don't see anything wrong with that. It's just part of the deal. You aren't just taking from them, you are also giving to them. There's an exchange between consenting parties.
What would be unethical, I think, is any service that forbids you to use another service or intentionally sets up a situation which would make it hard for you to use another service by not being compatible with common tools or not giving you access to your data (e.g. somehow disallowing git-svn, and so on).
Services spanning these various hosts will be inconvenient and difficult to maintain. For the above mentioned reliance on search engines to generate traffic take care to chose a name that differentiates your project from the web noise. A clear indication that traffic will not arrive is if your project first gets a re-recommendation on spelling. Take for example the people who brought you the chattr project from GNU. Immediately chatr is suggested as the proper search and your traffic will suffer accordingly.
as i has already been said having to maintain the code on several hosts will make it more trouble then it is worth. What you have to think is you would need to make sure that it uploads properly over several hosts, it would more then likely cause confusion to some over if one copy is legit and the others aren't which in turn could cause a bad name for the project before you even start.
End of the day there are much more, better ways to spread the word of your project, social networking sites, specific related forums are two main ones for you to consider, either way you would be better off spending your time posting to several sites then you would uploading and maintaining code on several sites.
I consider having several (independent) mirrors to be a benefit for the community, because such distributedness assures more reliable accessibility of your public work, now and in future (it will survive the failure of any single hosting site).
That's why I want to keep track of the available diffeent options to publicly host open-source projects:
Which public hosting sites for darcs projects are there?
Which public Git hosting sites are there that are free software?
I believe it's rather ethical (or moral) to put some effort into ensuring that your public work is published in the most accessible way (well documented, and with some guarantees about it being accessible at any moment when someone is interested).
The effort for you to push your work to several places independently (I mean, they won't depend on each other) and manage all this is probably not really a nightmare (as suggested in some other answers here), especially with a DVCS. For example, one can even set up Git so that one pushes to several places with just one command.
I feel that unless you are forcing someone to read something done by you, but you are rather just putting your stuff somewhere for it to be findable and accessible if someone is interested, you are not egoistic or ego-whatever.