@SeanGallardy We use it a little bit here, but I haven't had any hands on with it yet, so can't really comment on its usefulness to complexity ratio.
I think one use case we had for it was to integrate a form into our database, but it was pretty limited on how to input the source data and output the results, so we just found it easier to code our own website instead lol.
I think the industry these days is trying to come up with low-code / no-code solutions for companies, but then they end up being very limited technologies in what they can actually accomplish, unfortunately.
Anyone know a reliable way to check if a trigger being fired was the result of a DML action from another specific trigger. Any chance the EVENTDATA() function stores anything related to the call stack?
It only really matters what the majority of SO mods decide to do anyway
I don't feel especially strongly about the issue at the moment. It's not like this isn't par for the course behaviour from the company in recent years.
Can you make changes to the first trigger? e.g. to use SESSION_CONTEXT/CONTEXT_INFO? — Martin Smith5 mins ago
LOL
People and their comments. Just answer the damned question why not.
Moderator Note: This question being featured is still the best tool we have to announce this policy sitewide. However, people have been using this for protracted debate and discussion. As such, this question is now locked. If you want to discuss this policy further, or suggest other related chan...
> Specifically, moderators are no longer allowed to remove AI-generated answers on the basis of being AI-generated, outside of exceedingly narrow circumstances. This results in effectively permitting nearly all AI-generated answers to be freely posted, regardless of established community consensus on such content.
We recently performed a set of analyses on the current approach to AI-generated content moderation. The conclusions of these analyses strongly indicate to us that AI-generated content is not being properly identified across the network, and that the potential for false-positives is very high. Thr...
Your policy on making policies is crystal-clear:
Stack Exchange, Inc. agrees that it will:
[...] Post previews for review of all new official policies in the Moderators Teams instance with the policy tag, marked with links to their public version once published, and maintain a listing of all off...
What would be a legitimate, not terrible, use case for SESSION_CONTEXT()? Just curious.
@PaulWhite I contemplated this, but I care about a specific trigger as the source, and there could be other parent triggers in the call stack I want to ignore.
You can use TRIGGER_NESTLEVEL with an objectid parameter
IF TRIGGER_NESTLEVEL(OBJECT_ID(N'dbo.OtherTrigger', 'TR')) > 0
BEGIN
-- do stuff
END;
The EVENTDATA() function is only relevant for DDL triggers anyway.
You probably don't want over use SESSION_CONTEXT where a better solution is available. There were problems with using it in parallel plans. "The total size of the session context is limited to 1 MB. If you set a value that causes this limit to be exceeded, the statement fails."
> This example shows how a middle-tier application can implement connection filtering, where application users (or tenants) share the same SQL Server user (the application). The application sets the current application user ID in SESSION_CONTEXT (Transact-SQL) after connecting to the database, and then security policies transparently filter rows that shouldn't be visible to this ID, and also block the user from inserting rows for the wrong user ID. No other app changes are necessary.
Huh interesting. 🤔 Seems like a workaround to implementing proper authentication from the application.
Though I suppose I could see there being edge use cases where different users have access to execute an application process that is ran from an elevated account, but still needs some sort of additional RLS applied for each user who runs said process.
@JoshDarnell Maybe not best terminology, but yea IMO, most applications should connect to the database as the actual executing user, unless it's a particular service.
@PaulWhite You're saying by using a dedicated account, ay?...because my view is one shouldn't have to hard-code the account to the connection string. I prefer using a trusted connection that passes off the calling user's Windows identity, and connects to the database as the actual calling user.
Otherwise, if you mean the user themselves can connect to the server outside of the application, yes I agree - but that's a good thing, I believe. Typically a user has the same rights to the data regardless of where they're establishing a connection from, whether it be DesktopApp1, WebApp2, or SSRSReport3, etc. I believe proper security at the database level should control that for the user, regardless of where they make the connection - not the application itself that should be the gatekeeper.
Application roles do not eliminate the need to supply initial connection credentials. One must first successfully authenticate to the server/database using a login (SQL or Windows account/group), or contained database user) before an application role can be activated.
Application roles mostly d...
@J.D. I'm not talking about putting credentials in a connection string. The web app connects to the database using integrated security, but the web app does not practice "impersonation" of the end user. So the web app connects to the database as whatever user runs the web app process.
In the case of apps running in IIS, this is whatever the application pool user is - whether that's a service account, or a computer, managed service account, etc.
Impersonating the end user only really works if the end user's identity corresponds to a Windows identity, which isn't always, or even usually, the case.
@JoshDarnell Gotcha. And what's your typical process to secure actions or data access per the calling user?
@JoshDarnell Most of my experiences the users always have had a Windows identity. But most of my experiences have been for internal applications for an organization that is primarily on a Windows domain.
@J.D. Ah, okay. I'm often working in external facing and multi-tenant cloud environments. So users could be on various domains, etc, compared to where the actual web app and DB sit.
@JoshDarnell Yup, that makes more sense. I worked for a SAAS company when I worked at the FinTech company, so the primary apps they created were external, probably similar idea.
@J.D. There are lot of ways application authenticate users. One way I've used quite a bit is deferring that to a third party (e.g., OAuth or SAML "single sign on" workflows).
So a user might enter their email address (jdarnell@companyname.com), and based on their email address they would get sent to their Azure AD endpoint to sign in with their domain credentials. Azure AD then posts data to our system confirming the user is who they say they are.
@J.D. Yeah, we would have to use SESSION_CONTEXT or something along those lines.
Hah yea, not even thinking about EF at that point.
My mindset around security is probably dated. When I first did web, it was ASP.NET Forms, and impersonation was natively supported with setting the right properties in web.config. Nowadays, it does seem rather difficult to initially setup impersonation in .NET Core, especially across an API layer. But I don't do much application development anymore, I'm mostly in the database layer these days, so not my problem lol.