I'd like to ask is it smart enough to ship a web service/product without creating any CMS?
I mean in order to ship it faster and get some feedback from users it will be smart from my point of view to ship it w/out CMS and build it as you go but Im afraid from technical point of view - would it create any big problem that would be painful to solve?
Tnx.
Well, it depends on what you expect from the website. Should it be only a one-time web presentation, I think it might be okay to ship it without a CMS. I would also consider it fine if you didn't want to run a database for whatever reason (as most of the CMSs use database).
If the product is meant to be more complicated, it's definitely easier to start with CMS than to hack it in the product later.
However, if you decided for the latter way, you might find CouchCMS interesting. Though I haven't tested it myself, it looks very promising and easy to inject into an existing website.
Related
My team has been writing a dashboard application using Node.js, Twitter Boostrap, Mongo DB, and Mule for an ESB.
Recently an executive asked us to change our approach to a Portal/Portlet container like Liferay.
Some of us on the team have experience with Liferay, and we have pretty negative feelings about it. Dealing with things like full-page refreshes, portlet lifecycles, style and theming issues, and limited DBMS coverage are at the top of our list of complaints.
We see where our executive team is coming from. They have decided that they want to make the dashboard extensible and easy or easier to plug into for other groups.
Is there a solution out there which can balance the modern web expectations of users with the enterprise needs of IT professionals and executives concerned with building and extensible application with something like Liferay? Pluggable widgets are important here.
Node would obviously be our preference with something like Grails as a close second.
Thanks,
This question may not exactly be a good fit for StackOverflow's format, but I can offer some thoughts still.
If you want to stick your current platform, you need to figure exactly what features your executives want to get out of moving to a new platform. Are those features something you can build into your current platform? How much effort will that take compared to rewriting everything else? How effort will it take to learn a new skillset across your whole team? I'm sure your team can learn the new skills effectively but that still takes effort and there will be growing pains as your teams learns. If you can show to your executives that you can get the same features for a similar or less effort and that you can still have similar total cost of ownership, you can make a case to stay on your current platform.
Also I think you are underestimating what a Portlet container can do. I work mostly with WebSphere Portal so maybe thats why I think most of the pain points you mentioned really aren't that difficult to manage for me. Just because your container needs a particular DBMS to manage itself does not mean you can't use a separate DB for your custom data needs. JSR-286 introduced serveResource as a way to make AJAX easier to implement in portlets. In WebSphere Portal (don't know about Liferay), changing out the whole page content without a page reload might the most difficult on your list I'll admit though.
Modern doesn't have to mean bleeding-edge tech. And the large software products can still perform if you know how to use them right, just like any other tool.
I will soon be developing an application to log and priorities worker shifts. It only needs to be small, and simple, but I am wondering what framework to use. All that needs to happen is boxes with names are in 3 lists, and the user can switch these around at will. It must log the times, which I will need access to in real time.
Im new to application development of this sort, and would like any suggestions. I have time to learn new technologies / languages.
Portability / device independence would also be useful. Should I consider a Web Application in Javascript? or something more like Python.
Thanks.
Even if your application is going to be simple that does not mean that whole system will be simple too. I can imagine that your app will serve only as a front end to something much bigger. If that is a case and you really have freedom to choose what language you will develop your app with consider choosing something that you will feel comfortable to work with. But before you will make your decision I would go to whoever gave you that task and try to get as much information about it as you can because expected features can help in choosing technology.
First of all, it seems that it is up to you to decide if it should be web or desktop app. In my opinion it is completely wrong situation. You should get clear requirements on what kind of application customer expects and in what environment it should work. And I would not move a finger towards a code before somebody gave me that information. You write that portability and device independence would be useful but is it actual requirement or you just think it would be nice feature to deliver?
EDITED (to answer a question in comment)
Probably there is as much possible solutions as people that would answer you so in the end you will have to make your own choices.
One way of doing it (considering that you want to learn something new and have a challenge :) would be implement WCF service that would act as a data provider from your database (so every GetUsers(), GetVacationDays() methods would be in it) and it would take care of some business logic (for example CalculateMaxValidWorkingTime() or whatever). That service would be a real power horse of your system. Since you don't have clear requirement whether it should be desktop or web app you could satisfy both possibilities by creating thin clients that would communicate with your service and they would be just a pretty front ends. And if you keep in mind that you can consume webservices practically with everything from C++ to .NET (C#/VB) to Javascript to Python to PHP after you done with service you would not be constrained with one particular technology/language.
Regarding databases I won't advice because personally I hate dealing with them and it always was somebody else's task to provide me with pretty API :)
I want to rewrite a complete community website in nodejs,express and
nowjs with mongodb. Its currently in php using the codeigniter
framework. It includes functionality such as your own profile page,
photoalbum, guestbook, internal messages, contacts and more. And im
going to add an im to it and some other things like a forum and so on.
Its a pretty big project.
I have to make a decision about which techniques to use in the
webapplication. So i did a little research and found, node, Expess and
nowjs.
Should i stick to finish the application in php( codeigniter ), mysql
and ajax, or can i do this in express, mongodb and nowjs?
Can anyone recommend this for use on a live production site? And if
so, are there any security issues one should know about? General
guidelines?
Help would be really appreciated so i can make up my mind and finish
the project
Regards
George
The problem with Nodejs being young is not that it's a half baked product or something but infact it's growing very fast and new developments are being done at breath taking place. So you need to keep up with them while developing.
Otherwise there are huge projects out there developed totally with node and express. Take a look at expressjs.com/applications to see what kind of commericial projects are built using it.
As far as security, sessions etc. are concerned. Unlike ASP/PHP , you don't get most of the features out of the box. You'll need to either write them yourselves or using open source frameworks. Both ways you and only you have to ensure that your application has all bases covered. With flexibility, comes complexity.
It should be noted that Nodejs is optimum for real time I/O. If you think this is something which is required at your end then I highly recommend to go for it.
What you describe does sound like a big project.
If you have the time to spare, I would suggest picking a small portion of it that deals with managing secure sessions (e.g. the profile page). Implement that in Express to get a sense of how it compares to the existing PHP. If you like it, keep going.
Particularly when security is at stake, always try to use existing components when they are available. Node's minimalism makes it tempting to 'roll your own,' but it's very easy to make a security mistake with anything less than expert knowledge.
From a usability perspective, is it better to integrate admin section on the main website or have a separate section to manage content?
Any thoughts are greatly appreciated.
EDIT: the application is a CMS for very non-techno friendly staff.
It depends on the project and part you want to administer, imho.
For example comments on newsposts should be administered in the website itself by showing a "delete" linkbutton for each comment. Otherwise the mods would have to look up the comment in the admin section => not very user friendly.
But in general I think a seperate admin section will usually be more clear to your client. You'd want them to see the site as a normal user would see it.
At the very least I would recommend moving all your administration files to a separate folder. That way if you're using a platform like .NET you can very easily control folder access though role and user-based web.config permissions.
Having your administration files all segregated allows you to do other things easily too, like delete them if you decide to move them to another server later. Also you can exclude them in your robots.txt file (although by putting it in the robots.txt file you will be telling other people this section exists, and robots don't have to mind this file).
Edit:
I feel like my answer missed the mark a little considering your question. Of course in-line editing is easier than going to a separate page from a usability perspective, but whenever I hear of mixing admin users with regular users giant alarm bells go off in my head.
I think that it depends on the function of the site and how intrusive it will be to your staff. Does it make sense for them to make changes while browsing the site and will they eventually become discouraged with your system because it forces them to inject unnecessary steps into their process? How long will the edits take? Does it make sense to show a completely different interface to administrators? I think an answer to this question requires a lot more understanding of what specific function you're trying to accomplish and will vary on a case by case basis.
I have never liked adding administration pages into the main site. It seems like it is too much of a risk from someone accidently getting access to the administration portion of the site. Even if you review the security over and over, there is always that possibility that something unexpected will happen, and it is a huge mess to clean up (what was modified, who accessed what etc. etc.). In my opinion keeping it as a seperate site is the easiest way to go.
While there is a level of convenience in being able to login to the main part of a site as a privileged user, and then clicking on parts of a page to edit/alter it, there is also a measure of security in having it in a separate area.
I have found that having a separate section of the website that is devoted specifically to administrative tasks makes the tasks easier to organize and use. Just look at Wordpress (especially the new 2.7 release), Drupal (a very popular cms), and Joomla (another very popular cms). If you would like to test these feature out to see why I think the separate section is better, you can go to www.opensourcecms.com and test out both Drupal and Joomla.
From a usability, the more integrated the better but it tends to add severely to the complexity. Its always best if you can perform the action within the context in which it occurs - lock out a bad user, trim a log thats too big etc. however since these tend to have significant side effects the security aspect trumps this a lot of the time out of fear.
I think you need to look at doing a risk assessment with regards to integrating the administration capabilities right into the application.
What would be the implication for the system if someone were able to escalate privelages and gain access to the admin functions. if every user was locked out maliciously - damage to the site, the reputation, SLA etc?
What destructive functions can an admin perform from this section ? delete lots of data? crash the app? alter costs that have material impact on users/customers?
Are the admin functions integrated in the app or isolated into specific admin functions?
Does the application have a public face or is it an intranet that is assumed secure?
I personally have never felt at ease integrating the admin section with the site out of fear that a security breach caused by my ineptness or something beyond my control like bad defaults, unpatched exploit. However, when the client is writing the cheque I tend to do what they feel is best.
I come from the school of Usability that says "minimise guess work". So, what kind of information did you get from your user group sessions?
Remember, you're not (and we're not) typical users of your system. Anything we say is going to be a guess. What's worse is that any opinion shown here is likely to be ill informed for your situation (but probably awesome at what they do). The only way you'll have an informed opinion on what to do is by going out and asking your users in intelligent ways.
Because this is a security issue some of your user mix should be people who specialise in security. Just because it's easier to use doesn't mean it's the most appropriate.
I don't know much about poking at servers, etc, but in light of the (relatively) recent Wordpress security issues, I'm wondering if it's possible to obscure which CMS you might be using to the outside world.
Obviously you can rename the default login page, error messages, the favicon (I see the joomla one everywhere) and use a non-default template, but the sorts of things I'm wondering about are watching redirects somehow and things like that. Do most CMS leave traces?
This is not to replace other forms of security, but more of a curious question.
Thanks for any insight!
Yes, many CMS leave traces like the forming of identifiers and hierarchy of elements that are a plain giveaway.
This is however not the point. What is the point, is that there are only few very popular CMS. It is not necessary to determine which one you use. It will suffice to methodically try attack techniques for the 5 to 10 biggest CMS in use on your site to get a pretty good probability of success.
In the general case, security by obscurity doesn't work. If you rely on the fact that someone doesn't know something, this means you're vulnerable to certain attacks since you blind yourself to them.
Therefore, it is dangerous to follow this path. Chose a successful CMS and then install all the available security patches right away. By using a famous CMS, you make sure that you'll get security fixes quickly. Your biggest enemy is time; attackers can find thousands of vulnerable sites with Google and attack them simultaneously using bot nets. This is a completely automated process today. Trying to hide what software you're using won't stop the bots from hacking your site since they don't check which vulnerability they might expect; they just try the top 10 of the currently most successful exploits.
[EDIT] Bot nets with 10'000 bots are not uncommon today. As long as installing security patches is so hard, people won't protect their computers and that means criminals will have lots of resources to attack. On top of that, there are sites which sell exploits as ready-to-use plugins for bots (or bots or rent whole bot nets).
So as long as the vulnerability is still there, camouflaging your site won't help.
A lot of CMS's have id, classnames and structure patterns that can identify them (Wordpress for example). URLs have specific patterns too. You just need someone experienced with the plataform or with just some browsing to identify which CMS it's using.
IMHO, you can try to change all this structure in your CMS, but if you are into all this effort, I think you should just create your own CMS.
It's more important to keep everything up to date in your plataform and follow some security measures than try to change everything that could reveal the CMS you're using.
Since this question is tagged "wordpress:" you can hide your wordpress version by putting this in your theme's functions.php file:
add_action('init', 'removeWPVersionInfo');
function removeWPVersionInfo() {
remove_action('wp_head', 'wp_generator');
}
But, you're still going to have the usual paths, i.e., wp-content/themes/ etc... and wp-content/plugins/ etc... in page source, unless you figure out a way to rewrite those with .htaccess.