The basic requirement of the site is to provide a plateform for blogging and single interface for managing various social network, emails, blog etc.
For blogging I am using .netblogengine. And facebook and gmail and blogger are currently being managed by signing in via their api.
I am using mysql and blog content is being saved in mysql column.
My first question is.. Suppose instead of saving blog content in mysql table column I just save the content in a txt file and save the name of the file in the column.. Doing so will reduce the size of table but will it also affect the performance?? I know I will not be able to search within the content but mysql size grows up quickly (50 mb with 8 users). The minimum number of users are atleast 30.
My second question.. I am thinking of asking all the acount (facebook, gmail etc) username and password and store them in the db. When even a user sign in all related account will be signed in using the saved data so that separate logging is not required. How ever username/password hacks are common headlines now days. I want to know how secure are the shared server environment in this regard? Will I be required to take some extra effort to secure these data or I can be sure that as long as my mysql logging details are safe all data are safe.
The short answer is saving text content like blog post in the database is going to be the best bet. Saving any attachments if there are any in separate files is a good idea though.
The data size on your disk is going to be similar either way, so there's no savings there. And since you would need to develop a unique naming convention for the text files you'd essentially be programming a partial database yourself; might as well leave it to the experts :)
In general, the table size getting to hundreds of megabytes is not going to hurt performance substantially. Assuming you've set up your indexes appropriately, the database engine will be able to seek directly to the data it needs.
Short answer on the account credentials, definitely don't save either username or especially password in unencrypted form in the database. It would be a question for the security experts on how to properly encrypt these to ensure security. https://security.stackexchange.com/
Related
I'm reading on hash table and data structure, and one question come to mind. Where is hash table implemented? Is it on server code or database?
The resource I've read seems to implement them on the server code, but isnt storing data the job of database? PS: I've havent get to a point of knowing non-sql database yet, maybe that's where my knowledge lack.
Many applications need to store some data internally, even if they're also using or updating data in a database at times. Often they'll even retrieve related data from a remote (across the network) database and have it available in RAM on the local machine for the application to access quickly.
Other times, an application may use a data structure such as a hash table to support some application behaviours that are not part of the business data model, and therefore don't belong in the database. For example, a GUI application might keep help strings to display when the mouse hovers over a widget/button/whatever - they might be stored in a hash table keyed on some GUI object identifier, screen region or whatever the GUI library finds useful to help it display the tooltips at the right time. Another application might keep a table of usernames and activity statistics that it generated by scraping some website - it might display them to the user on demand, or aggregate them or something, without ever saving them down to a database (historic data may be of no value, and it can scrape the website again).
In summary - non-trivial programs tend to use hash tables to provide quick access to the data they consult or manipulate, whether the programs are themselves databases, applications that do also use databases, or applications that run without any database support.
I want to store an API key for a service that the WordPress plugin I am developing needs to get information from an API. There are two options that I am aware of:
1) WordPress's options mechanism
2) Create a new database table
As far as I can tell, at the end of the day both are the same in that they are storing the information in a MySQL table and that data could potentially be accessed by another plugin.
Is there any way to store data so that it cannot be read by other plugins?
Is this even a concern I should be worried about?
A plugin can potentially dump your entire database and send it to it's authors through email, so one way or other to store it's pretty much useless.
This boils down essentially to 2 things, store it in an external database, where just your plugin have access to that or just do a two-way encode/decode with a salted key so your plugin it's the only thing can decrypt it.
If database access from other plugins is still a concern then store the API key within your PHP file. It won't be replaceable but you can take MySQL off the list.
On a personal opinion unless you are installing the worst and least known plugins on Wordpress you probably should be quite confident about the security of your website. To be fair probably caring about an API key to be stolen is the least concerning thing when you have someone that could access all your user details and passwords and potentially FTP access to your server.
I want to store some data during my site viewing.
Sometime i need to store large data like crystal reports and some times i need to store a string.
So which is best to use and when to use.
Where are these datas stored. i.e., Client or Server
Please go through this link:
Nine Options for Managing Persistent User State in Your ASP.NET Application
What you are asking is about State Management in ASP.NET. What you have actually listed is Server Side state management options.
You can made a choice of which to use depending on your requirement or functionality.
I will recommend you do some background reading on MSDN regarding State Management. I am not sure which answer you need here as your query is a bit generic.
Here is a link to get you started... http://msdn.microsoft.com/en-us/library/75x4ha6s.aspx
This is a very open ended question. Ass Julius said you need to learn more about the different ways you can store information. For example, Application is used when you want to store information on the initial startup of the site and make it available to all users. Session is for a single user so you may have many sessions open depending on how many users you have online at that time. Cache is also a way you can store information on the server. All of these are stored on the server so if you have hundreds of users online at the same time, server memory will be consumed holding all this information. Rule of thumb is to try to be conservative when storing information in these locations. Personally, I rarely use application and also try to limit my use of session to when it makes sense. If I were to write an app that used crystal reports as you are, I would probably use sql to store the paramaters of the report and generate the report from the parameters but it depends entirely on the needs of the user using the app.
You can find a wealth of infomation on this subject on line. Hopefully this will give you some information.
Our requirement is something like this.
We are building a multi-tenant website in ASP.NET MVC, and each customer should be able to create their own users as per predefined user roles.
We are thinking about to create a schema for few tables which would be common for customers. So customer can login to system according to their schema logins and we need not to alter any queries to serve all of them.
We are referring http://msdn.microsoft.com/en-us/library/aa479086.aspx Shared Database, Separate Schemas.
Can someone suggest on following
1. After creating schema how to authorize user against a particular schema
2. Is this possible that without any changes in queries db can serve multi-tenants
Thanks in advance
Anil
After much research, I can say that, although it takes more development up front and more checks along the way, shared database and shared schema is the way to go. It puts a little bit of limits on how easily you can cater to a client's specific needs, but from my point of view SAAS isn't about catering to a single client's weird needs. It's about catering to the majority of clients. Not that it's a SAAS but take iPhone as an example. It was built to cater to the masses. Rather than focusing on doing everything it's built to be one-size fits all just by its simplicity. This doesn't help your case when it comes to authoriztion but it'll save you dev hours in the long run.
If you are asking this in the context of SQL Server authentication/authorization mechanism, i can asnwer this question with saying that every user has a default schema which helps query engine to find out required object in the database.
SQL Query Engine will look at the user's default schema first to find the required object (table). If it founds the object in user's schema then use it, otherwise goes to system default schema (dbo) to find it.
Check this article's How to Refer to Objects section to find out how it works. The article also has some information about security concepts related to schemas.
My company is building an ASP.NET HR application and we have decided to create one database per client. This ensures that clients cannot accidentally view another client's data, while also allowing for easy scalability (among other benefits, already discussed here).
My question is - what is the best way to handle security and data access in such a scenario? My intent is to use a common login/account database that will direct the user to the correct server/database. This common database would also contain the application features that each user/role has access.
I was not planning to put any user information in each individual client database, but others on my team feel that the lack of security on each database is a huge hole (but they cannot articulate how duplicating the common access logic would be useful).
Am I missing something? Should we add an extra layer of security/authentication at the client database level?
Update:
One of the reasons my team felt dual user management was necessary is due to access control. All users have a default role (e.g. Admin, Minimal Access, Power User, etc.), but client admins will be able to refine permissions for users with access to their database. To me it still seems feasible for this to be in a central database, but my team doesn't agree. Thoughts?
We have a SaaS solution that uses the one DB per client model. We have a common "Security" database too. However, we store all user information in the individual client databases.
When the user logs into the system they tell us three pieces of information, username, password and client-id. The client-id is used to lookup their home database in the "security" database, and then the code connects to their home database to check their username/password. This way a client is totally self-contained within their database. Of course you need some piece of information beyond username to determine their home database. Could be our client-id approach, or could be the domain-name requested if you're using the sub-domain per client approach.
The advantage here is that you can move "client" databases around w/out having to keep them synced up with the security database. Plus you don't need to deal w/cross-db joins when you're trying to lookup user information.
Update: In response to your update... One of the advantages to each customer having their own DB is also the ability to restore a customer if they really need it. If you've split the customer's data into two databases how do you restore it? Also, again, you'll need to worry about cross-db data access if the users are defined in a DB other than the home DB.
I've always been of the opinion that security should be enforced at the application level, not the database level. With that said, I see no problem with your intended approach. Managing accounts and roles through a central database makes the application more maintainable in the long run.
You may want to look into using the ASP.NET membership provider for handling the authentication plumbing. That would work with your stated approach and you can still keep all of the authentication data in a separate database. However, I agree with Chris that keeping one DB will utlimately be more maintainable.