今日已更新 257 条资讯 | 累计 40702 条内容
关于我们

标签:#iss

找到 23 篇相关文章

AI 资讯

Giving AI Agents the Same RBAC Rules as Your Users: Building a Laravel Permission Layer LLMs Actually Respect

AI agents don’t use web browsers. They don’t click buttons, submit forms, or trigger standard HTTP requests that pass through your middleware stack. They execute logic via API calls, background queues, or CLI commands using tool definitions. When an LLM decides to "fetch the latest invoices," it usually calls a tool function. If that tool function just runs Invoice::all() , your AI agent just became a god-mode data leak. The fundamental problem with integrating LLMs into existing applications is that agents operate in a detached, stateless execution context . They don't have a session cookie. They don't inherently know who invoked them. If you rely on the system prompt to tell the LLM, "Only show John his own data," you are trusting a probabilistic text generator to enforce your security boundary. That is a production incident waiting to happen. To build a secure AI agent in Laravel, you must treat the LLM not as a user, but as a proxy for the user. The agent must inherit the exact Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) constraints of the human sitting behind the keyboard, and it must enforce those constraints at the database query level, not the prompt level. TL;DR AI agents bypass traditional web middleware because they execute logic through background tools and function calling. Never trust the LLM to filter its own results. Force filtering through Eloquent scopes and authorization gates. Pass the acting user's identity explicitly into the agent's execution context using Laravel's auth guards or custom context DTOs. For complex rules (hierarchies, multi-tenancy, ABAC), standard role packages fall short. Tools like hosseinhezami/laravel-permission-manager are required to evaluate deep permission trees inside agent tools. Audit every tool execution with the acting user's ID, not the system service account. 📋 Table of Contents 1. The "God-Mode Tool" Problem 2. Passing Identity Down the Execution Chain 3. Enforcing RBAC Inside LLM

2026-09-06 原文 →
AI 资讯

Beyond the Bug: Unpacking the 'Copy Link' Glitch in GitHub PRs and Its Impact on Developer Productivity

In the fast-paced world of software development, every second counts. Seamless tool interaction is not just a convenience; it's the bedrock of high developer productivity . Even seemingly minor hitches, like a non-functional 'copy link' button, can subtly erode efficiency, leading to frustration and lost time. A recent GitHub Community discussion highlighted just such an issue, where a user reported that the 'Copy link' button in Pull Requests (PRs) was consistently failing, specifically when using the Arc browser on macOS. This isn't merely about a broken button; it's a window into the complex interplay between browsers, web APIs, and the essential tools we rely on daily. The Reported Problem: A Month-Long Frustration The original post by vovapyc detailed a persistent problem: the 'Copy link' button in GitHub PRs had been broken for at least a month. The user specified their setup: Arc browser, MacBook Pro M1 Pro, and macOS 26.2. For dev teams, product managers, and delivery leads, a recurring point of friction like this, preventing a quick share of a PR link, represents a tangible drag on workflow. Imagine the cumulative time lost across a team if every developer had to manually copy URLs from the address bar multiple times a day. GitHub's automated response, while a standard and necessary part of their feedback loop, acknowledged the feedback and assured the user that their input would be reviewed. However, it didn't immediately offer a solution or explanation for the bug, leaving the user, and potentially others experiencing similar issues, in limbo. Diagram illustrating the three gates: Secure Context, Document Focus, and User Permission, that must be passed for the Clipboard API to function.## The Expert Insight: It's Likely the Browser, Not GitHub The true insight, and the crux of this discussion, arrived from hoangperry . Their comprehensive breakdown suggested that the issue was almost certainly browser-specific rather than a core GitHub bug. This distincti

2026-09-04 原文 →
AI 资讯

Cloudflare Cuts Astro Github Issues by 85% with AI Agents

Cloudflare, Astro, AI agents, GitHub Actions, issue triage, agentic AI, software architecture, open source, developer tools, AI automation, automated testing, human in the loop, agent workflows, GitHub, software engineering, AI software development, bug triage, continuous integration, developer productivity, autonomous agents, AI coding, Cloudflare Workers, Flue, triagebot By Leela Kumili

2026-08-21 原文 →
开发者

Directus Basics Part 3 — User Roles & Permissions

This is part three of our Directus Basics series. In part one we set up our instance, and in part two we covered relationships between collections. Today we're covering access control — what determines who can see and touch your data. The Core Concepts Access control in Directus comes down to three terms: Permission — applies to one collection and one action (create, read, update, delete, or share). Can be full access, no access, or custom rules. Policy — a group of permissions bundled together, applied to users or roles. Role — defines a user's position within a project. A role can hold any number of policies, apply to any number of users, and have child roles of its own. What Happens Without a Role? If an administrator creates a user but doesn't assign a role, that user has valid login credentials but still can't access the Data Studio. Creating a role and assigning the user to it isn't enough either — logging in at that point returns a "No App Access" error. The missing piece is that the role has no access policy attached. The policy is what actually tells the role what its users can and can't do. The Access Order Access in Directus flows in a specific direction: Access Policy → Role → User In practice: define what level of access a user needs, build an access policy to match, create a role and attach that policy to it, then register the user and assign them to the role. Default Policies Every fresh Directus instance ships with two default policies: Administrator — the role you're signed in as by default, with unrestricted access to everything. Public — for data that should be visible without logging in. Think of a product catalog on an e-commerce site — forcing a login just to browse products is a poor experience. Rule of thumb: give the Public policy Read access only. Never Create, Update, or Delete. The public should be able to view data, never manipulate it. Giving a Collection Public Access Go to Settings → Access Policies → Public Under Permissions, click A

2026-08-21 原文 →