When using some existing forum software in a larger web-site, how easy is it to:
1)Make your site's login functionality log the user into the forum
2)Make your site's registration functionality create forum login data
I suppose in a way it might be easier to ONLY use the forum's database for maintaining users, but that means trusting it with sensitive data.
I'm planning an integration between an existing bespoke desktop app and a new bespoke web-site which should include forums. I don't know which forums will be used but I know the new web functionality won't be PHP-based. I figure that's not a big deal but I'm wondering if forums typically allow configuration of where they look for login data, to avoid duplicating this data into my DB and the forum DB.
It's usually pretty easy, but it completely depends on the Forum software that you choose.
I've written systems in both PHP and ASP.Net (C#) that integrate with phpBB or vBulletin databases.
The login functionality is the easiest part to implement because the hash is stored in the DB (usually a salt will be too), and you just need to check one field to another and voila you can authenticate!
The registration of users is a little more difficult.
The way I did it was browsing through their source code to find out what SQL commands were necessary during the registration step.
So, depending on the forum software you choose, the difficulty will change, but overall it's not to difficult to make happen.
I would offer you snippets on how to integrate with PHPBB and VB, but since those are both PHP based, you said you weren't going to use them.
You are actually looking for a Single Sign On feature, that is integrated in several forum softwares, like Simple Machines and JForum for example.
Related
I have a web application with a user base. I want to add a forum, but I don't want users to register there again.
I'm using Rails/Postgresql.
Is it possible to integrate the forum so that after registering in my site, a user will also be registered in a forum?
Thanks
Yes, it's possible. The simpler way is to centralize registering and authentication through the forum.
Implementation depend of what kind of forum you use and the structure of your site.
The packaged forum should have some kind of API that you can use to programmatically add a user when they register with your main site. If not, you can just write to the tables yourself (which is considerably riskier, but certainly doable if the forum software isn't ridiculously complex and over-engineered).
You may need to add some fields to your site's registration if the forum software requires some that you don't already have. If that's the case, the bigger challenge will be integrating existing users. You might have to use dummy values for them, or prompt them at their next login to supply the necessary values in order to complete their forum registration.
I am planning to get my website development outsourced to a third party developer. Need your help in deciding on how/ what technology to be used to make it very secure. Since I am not a techie I need the website developed in a way, so that it is easy for me to maintain it and modify content easily if required.
The main purpose of the website is to provide company information about services offered and then also to exchange documents and other file using FTP server. Will be sending out surevey and newletters sometime
Looking for your advice to guide me to the right direction
As I already said on another answer, security is not a product, it's a process.
There isn't a 'secure' software or language. What makes your website/application secure is how it is developed and how the website is maintained.
There is no ready-made solution that, one time or another, won't be hacked.
If the people you are outsourcing to don't understand this, outsource to someone else.
Making your web server "hardened" against attack is best left to the expert sys-admins at Server Fault. However regardless of what technology you use, there is one HUGE thing an end user can do to protect her/his online assets:
USE STRONG PASSWORDS
You can make a site secure using any technology/language/framework.
It's the code quality that makes a site insecure, not the technology/language/framework.
There is no single "correct" language to use -- it's possible to write an insecure website in any language.
The key is hiring staff that have the skill and experience in developing secure web solutions, and also making sure that the system is tested often by external specialists
I've been building a static website and the client has suddenly stated that they would like the ability to change the content( words ) and pictures when they feel like it. What is the best way to do this? I could build something, I just want to make sure there isn't already something out there. I need this to be a simple as possible.
Use a CMS; a Content Management System.
There are plenty of open-source ones. Wikipedia has a list of many CMS's here.
You'll need to decide on a CMS, and set it up. Afterwards, it becomes a matter of styling the CMS after the theme of the static website you have designed. You probably can find many tutorials online, depending on the CMS you choose (that could be part of your criteria).
You can use one of many content-management systems.
Drupal is a very popular content-management system with years of development and a very large user base.
You could also use WordPress, not strictly a content-management system, but because of its flexibility may be suitable to your or your clients needs.
Here's an article on some content-management systems.
Even though there are many good CMS tools out there, I've decided to roll my own tools for my website to get some hands on experience. The only thing that is currently eluding me is how to add authentication to secure the administrative tools.
I'm the only one who will be using the administrative tools, so I don't need something as complex as a full-blown log-in and registration system. However, I also don't want to rely on security-through-obscurity and use random page names and such to hide the tools.
What are my options?
OpenID is probably your best bet.
To utilize it for one person as you suggest, just check the username that is authenticated. Yeah, that would amount to hardcoding, but if we're creating a system with only one valid login name, there's no need for anything more complicated.
But creating the alternative shouldn't be that bad. You could also just create a table of roles, and do a query against that table to see if the currently logged in user is an admin. If you want to be fancier later, you can later add different users and roles.
How the users and roles get into the table is up to you.
1) Simply use "WWW-Authenticate: Basic" see Wikipedia for an idea and the related RFC for details.
2) Enable SSL to ensure your cleartext password is encrypted.
SSL is quite standard on web servers. You can even self-sign your certificate.
This will depend in part on what platform will be used by you and your web host. A given platform will likely offer one set of choices that will be easier to access than others.
For instance, ASP.NET running inside of IIS offers Forms, Basic and Windows (NTLM) authentication, as well as certificate-based authentication with the ability to map client certificates to Windows users.
You could certainly implement another authorization schema in an ASP.NET application, and many do. But there happen to be this set of out of the box authentication schemes that you would not have to implement if this were your platform. I expect this is true of any other platform, including the Linux-based platforms.
Be sure to find out what's available out of the box, and what can easily be added, before writing your own.
Our organization started on the SharePoint path about two years ago. Before that, we (the developers) wrote mostly asp.net front ends for SQL back ends. Now it seems like every time a new project comes up, we are asked to “make” it fit in SharePoint; and we have stuffed some things into SharePoint that probably should have been stand alone applications or web applications due to complexity and interactions with other technologies.
My question is: Where do you draw the line as to developing a project in SharePoint versus Web/Winform application, and how do you convince your manager(s) that SharePoint may not be the best solution for a particular project?
I sort of agree with you that this is sometimes a tough question. In general, though, I agree with the cliche that you just have to think about a sharepoint app a little differently. If your data can be considered as list-based, then SharePoint probably isn't a necessarily bad development framework. It may seem like more work on the surface, but IMO the challenges just move from one place to another. If you use things like custom field templates and web parts, you can relatively naturally handle all sorts of data. And you get the positive aspects of SharePoint for free (an already mature security framework, built-in searching, site and list templates/definitions, personalized page customizations, yada, yada).
I also I don't know what you mean by "complexity and interactions with other technologies" here, so it's hard to imagine what specific issues might be introduced when SharePoint is added to the mix.
If your dev team is relatively inexperienced with SharePoint and you care about quality and deadlines, I can definitely see your point. It's not an easy learning curve, but I think the SharePoint product is more naturally extensible than many people give it credit for.
There is, in some cases, a third option between a SharePoint application and an ASP.NET application. You can build custom site and application pages and deploy them to a SharePoint site. (The book Inside Windows SharePoint Services 3.0 gives a good overview of how to do this.) This will allow you to use ASP.Net and SQL Server within a SharePoint environment (which means you can also take advantage of things like SharePoint security). It's not as easy as developing a plain ASP.Net application, but it's a compromise.
Of course, this is sort of a technicality if they're wanting these new applications to be built on SharePoint technologies (lists, libraries, workflow, etc.), not just to be "inside" SharePoint.
One of the primary reasons why you might put an applicaiton in SP is when you want to take advantage of the building blocks SP gives you:
Security (share security with the site)
Data (store some or all of your data in lists)
Provisioning (if you want you app on multiple sites)
Some basic data UI e.g. Lists give you that and you dont need to build it.
One thing to consider when trying to 'integrate' a new app into the existing pool is whether there is any overlap in data (customers, inventory, etc) that would benefit from the merger.
There is also the benefit of being able to back up multiple applications and all of their respective data in one place.
Why are they asking for it all to go into SharePoint?
In my experience it is because the 'ole SharePoint intranet is being great as a portal to keep everything together and findable under the one information architecture.
Approach the issue from a uses perception of the application space in the organisation.
So long as the application looks and feels just like part of the intranet site and the user does not have to think about how to get to it (and how to get back out), you can pretty much take any architecture decisions necessary to get the best bang for the organisations buck when it comes to implementation and maintainence.
When we started thinking about the site less from SharePoint vs other stuff to the nice woolly concepts of Information Architecture, findability and usability, our decisions not to make it actually inside SharePoint, but still skin it like the Intranet became easier to sell.