I am currently developing a business application that will ultimately be hosted at a .Net hosting company. The hosting company provides 1 MSSQL DB (with 2 users) and an unlimited number of MySQL DBs. Purchasing a second MSSQL DB is out of the question as my boss doesn't want to pay any more for the hosting. I am trying to determine the best place to house the ASPNETDB for site authentication and roles.
My first thought was to take advantage of one of the MySQL DBs for this purpose but have noticed that it appears to take some hoop jumping to accomplish this option. Another option may be to keep the ASPNETDB in a Express DB file.
Finally, I have also thought about housing it in the MSSQL DB with the application tables. This option scares me because if I accidentally screw something up in the application, the ASPNETDB tables could be open to SQL injection. Of course, I will do my best to ensure this won't happen anyway, but would like to know I have that extra layer of security knowing it is housed in its own DB.
The hosting company does allow two MSSQL DB users, so this in theory would allow me to have one user dedicated to authentication and restrict the other user from being able to access the ASPNETDB tables all together.
As a fellow developer, what method would you recommend? Thanks in advance for your help.
Use the MSSQL DB and use the preconfigured ASP.NET Membership provider and Roles provider. This is the easiest method. Restrict Table level access and use only Stored Procedures.
Sounds like you are a bit green to this stuff, am I correct? Because of that dont create too many headaches for your self. Dont try to put it in mysql, thats a mistake. I know its free, but it was written to work with MSSQL. Yes, using the other user is a good idea. Just be sure to sanitize your inputs and use properties on your SQL statements or better yet use an ORM like entity framework or Linq to SQL at the least.
Related
I'm looking into using CloudBees for some application prototyping. I am using free accounts right now, I am not paying any subscriptions at the moment.
The first step for me is to create a MySQL database to host my application's data. I've done so (and it was pretty easy!). I also use Liquibase to manage the database (I've started this work using local H2 databases for the pre-prototyping), and I've been able to construct everything as expected.
As part of checking whether liquibase created the tables, I brought up the MySQL database in NetBeans. And, it did function well. But I can also see other schemas as well as the schema I just created. They're all innocently named (test, test_6hob). But, I can see the tables and view their data.
My question is around the visibility of the data that's in the CloudBees database. Is the database created for the free accounts viewable to other people connecting to the same machine? Does this change if I use a paid account? Or is it more the nature of how the database was created? I can see other schemas (and their data) but I have no idea if other people can see mine? Is there a permissions-aspect I need to ensure I set? I've fairly ignorant with the inner-workings of MySQL.
While this is a prototype, were I to move into using CloudBees for production applications, I wouldn't want the data to be visible to anyone who happened to connect to the same database as my application. It's entirely possible that I'm missing something in this new cloud world. :)
Thanks for any info
All CloudBees MySQL databases are secured separately (although will be in shared instances unless you have a dedicated server) - they are not readable by any other account by default.
However, it is possible for the database owner to grant access to users from other accounts on that same database server if you really wanted to - even though it makes very little sense to do so (and your special user configuration will be lost during a failover).
So this is what has happened for the test databases that you can see - the database owner has opened up security on those databases / tables.
This question is probably off topic but i'll bite anyway. The database data is private to your account. Actual hardware/vm's maybe shared but the data/database is not.
I'm writing the entire database system for a factory, this includes inventory, payroll, incoming and outgoing shipments, job-data, customers, etc. The database will be stored offsite on a server running Windows 2008 R2 with SQL 2005. The guy who runs the server sent me this too:
"We also have quickbooks installed on the server and we have Exchange 2010 running. The terminal server is also ws 2008 R2.
There is plenty of horsepower on the primary exchange/file server. Let me know if you have any other questions.".
I know my boss uses Quickbooks to look at reports and stuff like that. I'm not sure how relevant exchange 2010 is, nor what the significance of "terminal server is also ws 2008 r2" is. My boss wants me to write the entire system in ms access 2010, but I feel like this will be a lot more work than simply writing it in MySQL. Will my boss still be able to look at his reports in quickbooks if we change the database to MySQL? What would be a good database technology to use? I feel the most comfortable writing it in a scripting language using MySQL, but would still be happy if I could write it in something like C/C++. I've been trying to learn access, and it seems that setting up a front-end and back-end database in access would be a pain in the ass. There are going to be several sectors in the factory that will be using the client-side software to run queries and insertions into the database(I think around 5-6).
If I can write this thing in MySQL, I think I could do the whole thing fairly pain free, but I fear that I can't because it will be incompatible with Quickbooks and the previous database(Although I hear converting is fairly easy). Mostly just Quickbook compatibility is my problem.
How horrible would it be to write this thing in Ruby?
Thank you, any help is greatly appreciated.
I don't mean to be a spoil sport but there is a tremendous amount of naivety expressed in this question. It's hard to imagine that you will be successful in designing and implementing such a large system without a basic knowledge of the technologies involved.
A few thoughts:
Quickbooks already covers most of the features you say you will be responsible for implementing. Are you supplementing the existing Quickbooks system, replacing it, or what?
Quickbooks uses its own (extraordinarily slow) database engine. It isn't "compatible" with SQL Server, MySQL, or Access.
SQL Server 2005 is a database. You don't use a database with it, you use it as your database. A Microsoft-centric organization such as the one you describe is not likely to be interested in installing yet another database server like MySQL.
MS Access encompasses both a database "engine" (called JET) and a desktop development environment. The engine can be used with other development environments and the development environment can attach to other database engines (most often SQL Server, but others work too). When you say the boss wants to write the system in MS Access you need to be clear whether he means the engine, the development environment or both. (My guess is they want to use Access as the front-end development platform and SQL Server as the data store).
You will not write a system of this complexity in a month. You probably won't even design it in that time.
Quickbooks can use MySQL as a datasource (or just about anything else), but you'll need to make your database conform to the Quickbooks way of doing things: i.e., your tables will need to match the QB table structures. It sounds like you just need a front end (data entry forms and reports) and a custom back-end. Access can quickly turn into a nightmare if you don't put in some up-front design thought, but it does give you forms & reports & web pages free in a neat little package. Make sure you use an Access Data Project (adp) that's connected to a SQL Server back end. Access does have its own native database, but everything gets stored in one local file and it's not good for applications that will be accessed by multiple people in multiple locations. It also gets complicated when you need to make a change and roll it out to all of your users.
Another option is to look into a customizable web platform, like SalesForce or MS Dynamics. That will also let you create your own tables, forms, and reports, and updates are immediate for all users, but you'll have ongoing monthly user fees. They look great on a resume, though!
Right now, in my internship, I'm assigned to create a system that holds employee information such as personal info, education, salary, etc.
All these stuff is kept in a few spreadsheets right now. I need a basic program, but I feel like I should be using MySQL or another database solution to hold the data. I used MySQL before, but it was a PHP/MySQL assignment which I used Wampserver to create the whole system.
Edit: The system will be used by a few computers across the network. When someone makes a change to the system, it will become visible to other computers aswell. (obviously) (Before the edit, I thought that it's gonna be used by a single computer.)
I'm confused right now. Should I create a PHP/MySQL webpage with wampserver (or similar) to hold the information, or not?
Would it be easier or better to combine MySQL with some other programming language (such as Java/C++) and build a GUI? (I doubt it)
Should I come up with a different solution? Without database usage?
Database usage would be the best option. In the end it will come down to what you are more comfortable using, Java/C++ or php, for what you want to do either can work, but remember the database will need to be live at all times and using wamp server wont cut it. You need to learn how to tun a mysql server without wamp, which is easy(Google is awesome). And personally I would have used Java because Java is also easy to link with mysql, just google it a bit, and java doesn't need to run on a server so no wamp needed as you would have needed for php.
EDIT:
Ok if I understand you correctly what you want to do is the following:
1. Identify a pc to be used as a server and assign it a static IP.
2. This must also be the pc that is turned on first every day and turned of last.
3. Create a front end client application that connects to your sql server that you will be running on the server machine.
Now I am assuming this network is rather small, so you wont need a specific computer to just act as server. The server can also be one of the client machines.
The best approach would be to create a mysql server and make sure the firewall is not blocking your sql server. Then create a client application that can access the database over the network using Java, I find this easier than creating a php server for the users because of port forwarding for an apache server is time consuming, I did it once and never again. Java will be easiest to make the application work over the network. Use Netbeans for the development, it's an awesome IDE and it makes life easier when setting up the database connection.
If you have anymore questions please ask in comment, and I will elaborate, since this might be a bit vague lol.
Of course you should use a database for this type of work. That is the best way to organize, search, sort and filter your data without having to reinvent the wheel.
As to the other questions, the choice of language and environment is up to you to decide after evaluating the needs of your application.
Your solution should use a database to store the data and an front-end application to manage the data.
The database and front-end should be seen as two separate layers. In other words create the database using whatever database your are familiar with eg: MySQL and likewise create the front-end using whatever technology youre familiar with eg: PHP.
Personally for this type of requirement i would typically use MySQL / SQLExpress and ASP.Net / MVC3 front-end.
Hope this is helpful.
I have been tasked with migrating an existing mature ASP.NET 2.0 web site to NHibernate, Mono and MySQL or postgres. I am somewhat confused as how the membership provider salts the passwords. If I make the switch and use the MySQL membership provider (outlined in this question) or AspSqlProvider, will the existing users be able to login?
I guess it would be easier for me to ask: How the hell do I get access to the encryption key used by the ASP.NET membership provider that salts the passwords so that I can use the same one in a third party provider?
How many users are you talking for this site? Is it publicly accessible, or something used within a company LAN?
Transferring your existing membership database to the schema generated by the MySQL provider could get interesting. I'm not even sure how similar the table schemas they use are, though I would hope they are quite close.
If the number of users is relatively small, I would strongly consider forcing a password reset upon changing to the new system.
edit just saw you added postgres while I was typing - if your database choice is still up in the air it may be easier to use an ORM-based provider that offers you a bit of portability (and consistent behavior)
if using nhibernate, I was recently looking for an nhibernate-based membership provider and ended up choosing this one: Fluent NHibernate Membership Provider (CodeProject). Got it to work for me with minimal modification, but its for a greenfield project without these concerns. It is on mono though :)
found this: Membership Providers - see the "DataSchema" section, aspnet_Membership table. Looks like getting the salt won't be a problem, so you should be able to get this working w/o password resets.
I am trying to determine the best approach when designing a new Access based application. Due to decisions made by others I have to use Access 2003 as my front end and SQL Server as my back-end data store (I would have preferred to use Winforms/WPF and SQL Server 2008 but that is another story).
Originally I was thinking of using Access Data Projects (ADP) as data security is a big issue in this project and ADPs would allow me to store everything (except VBA. reports, and forms) within SQL Server. Problem is that many developers I have spoken to suggest that using ADO is something that Microsoft has tried and then abandoned. They suggest using linked tables will provide a more consistent and less buggy experience.
I was hoping to get some feedback on what others think the best solution might be. Additionally, I would be interested to know if others consider linked tables to be a security risk over ADP. Thanks for any assistance.
Edit ... just wanted to add that the number of people using this application will be small (10 to 20). I should also add that this application is being developed from scratch. No conversion is needed.
ADPs have had no significant features added in a number of versions now. They also have some quirks compared to MDB/ACCDBs. There are probably less than 1% of the folks using ADPs who use MDBs/ACCDBs so support is much better for MDBs/ACCDBs.
The ADO part is immaterial as you can use either ADO or DAO.
If you use Windows authentication then there is no real difference between ADPs and linked tables as userid and passwords aren't stored in the linked tables metadata.
The number of users is immaterial. There is no reason why you couldn't have thousands of users in an Access FE against a SQL Server BE.