I have an application that used to work with membership. Now I switched to identity.
I can see the membership tables, stored procedures and views all over the place. They start with asp.net_<Name of the table>, asp_net_<Name of the stored procedure>, and asp_net_<Name of the view>.
For the identity, all I could find are 5 tables:
AspNetRoles
AspNetUserLogins
AspNetUserClaims
AspNetUserRoles
AspNetUsers
I've searched folders in the database, but I can't confirm whether besides the above 5 tables, identity uses other objects, such as stored procedures or views.
If that's the case, can I just script those tables and the create them in the test database? So that when I try to log in, I don't get an error?
Thanks for helping
Related
Wondering if there will be security issue with code-first and Entity Framework?
It will auto generate the three stored procedures for each table. For example, a table named tblAttachment will have auto generated stored procedures like this:
tblAttachment_Delete
tblAttachment_Insert
tblAttachment_Update
Application user is granted the permission to execute all three stored procedures and also SELECT all the tables.
If hacker got the credential of application user, basically he owns the whole databases since application user could do select / delete / update / insert the records. Should this be concerned? What is the best practice in here?
I know sybase supports two types of temp tables, one starts with # and can't be shared by sessions. The other one is created with tempdb.. prefix which can be shared by sessions or users.
My question is:
Are tables created in tempdb accessible to other users as well?
How to control the access or how to prevent the table created by userA from being modified/dropped by userB?
I googled for a while but didn't find any information on this.
I'm using sybase at work but don't have admin access to create new user so I can't do the test.
Can someone who have experience please advise?
please refer to http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc32300.1570/html/sqlug/X10118.htm for details.
i also test the behavior on sybase ase 15.7.
the result as same as the previous link.
Are tables created in tempdb accessible to other users as well?
Yes.
How to control the access or how to prevent the table created by userA from being modified/dropped by userB?
There seems no method about the tempdb..xxx tables.
I plan to pass exam 'Querying Microsoft SQL Server 2012'. I would like to better understand one question.
Question is:
How would you accomplish this task?
You work as a database developer
at ABC.com. ABC.com has a SQL Server 2012 database named SalesDB with
a table named Invoices. Application developers are developing several
in-house applications that will access the Invoices table. You need to
develop a solution that will allow the applications to access the
table indirectly while still allowing them to update the Invoice
table. How would you accomplish this task?
possible answers are.
A. You should create a view on the Invoices table.
B. You should create a columnstore index on all columns used by the
applications.
C. You should allow the applications access to the Invoices table via
stored procedures.
D. You should drop and recreate the Invoices table as a partitioned
table. Possible answers are
This is source: How would you accomplish this task?
They say that correct answer is C, but I don't know why? I think that correct is A, because view works 'indirectly' with data.
Thank for help.
The commented ownership-chaining of stored procs only come into place when the stored proc and the used tables have the same owner.
So I would like to point out another argument.
You can EXECUTE a stored proc AS another user. That means you could create a user without a login and grant UPDATE permissions. Let's say the name of the user is UPDATEInvoices. When you create a stored proc you can define that it has to execute as the comtext of the user.
So, when you give the user who wants to call the stored proc EXECUTE permissions he can UPDATE rows in the table because it runs with other permissions.
I would like to be able to store the tracking tables in a different database the original. For a couple of reasons.
I would like to be able to drop it on demand if I change versions of my application.
I would like to have multiple sync scopes separated by user permissioning.
I am sure through the sqlmetadatastore class there is a way, but I have not found it yet.
the sqlmetaadatastore will not help you in any way with what you're trying to achieve. am pretty sure its not in anyway exposed in the database sync providers you're using.
note that the tracking tables are not the only objects Sync Framework provisioning creates, you will have triggers, tracking tables, stored procedures and user defined table types. and you're not supposed to be dropping them separately or even dropping them by yourself, but you should be using the deprovisioning API.
now if you really want to have the tracking tables on a separate db, the provisioning API has a Script method that can generate the SQL statements required to create the Sync Fx objects.
you can alter that to create the tracking tables on another DB, but you have to alter the triggers as well to insert on this other database.
My database has been created with table names looking like this for the user information:
DROP TABLE [dbo].[webpages_Membership];
DROP TABLE [dbo].[webpages_OAuthMembership];
DROP TABLE [dbo].[webpages_Roles];
DROP TABLE [dbo].[webpages_UsersInRoles];
Is this somewhat of a standard when it comes to table naming conventions? If I now want
to make some new tables would it be reasonable to also name them things like
admin_application
admin_account
or do DBAs normally assign tables used to hold different things to different users when they want to group table types?
I would just like to find out how people normally group tables in an application. Am I
right to assume they are all under one owner in this case dbo or do people leave the
table names alone and have them stored in different owner accounts?
Yes, the best way is to use schemas to divide logically grouped tables. Good example of this is Adventure works database you can download from CodePlex. They have several schemas for different parts of the company such as Person, Production, Purcahsing, Sales and other. See more details on how MS designed this DB.
Have a look at schemas:
create schema webpages authorization dbo;
GO
create table webpages.Membership (...
create table webpages.OAuthMembership (...
create schema admin authorization dbo;
GO
create table admin.application (...
It used to be that before SQL Server 2005, you needed to create a database user in order to create a schema. However, since then, you can create schemas for organizational purposes. Schemas cannot contain schemas, so it's a single level. Schemas can contain any database object, i.e. tables, stored procedures, etc..
Schemas need to have an owner, hence the authorization bit above. Specifying dbo here will make it the same as if you had created it in the dbo schema.