don't pass widget ref around outside build
What the developer wrote
Authored by julian
don't pass widget ref around outside build
What changed, and why it matters
This is a small code-quality cleanup in a Flutter screen that shows ticket attachment details. It stops passing a UI framework reference (WidgetRef) into helper methods and instead passes the actual service object directly. There is no direct security vulnerability visible in the diff, but the change removes a pattern that can make code harder to reason about and could theoretically hide lifecycle bugs.
No immediate security action required. Treat as routine maintainability refactor. If reviewing for security, verify that ref.read(pShopinBitService) is only used inside build/onTap and that getAttachmentUrl still enforces authorization correctly on the server side.
Security signals we found
Refactor removes WidgetRef propagation outside build method
No change to authentication, authorization, or URL handling logic
No input validation changes
No cryptographic or secret-handling changes
Evidence from the diff
The patch refactors _AttachmentFileLink in lib/pages/shopinbit/shopinbit_ticket_detail.dart. Previously _open() and _resolveAndLaunch() accepted a WidgetRef and used ref.read(pShopinBitService) to obtain the ShopInBitService. Now the service is read once in the build method’s onTap closure and passed as a typed parameter. This reduces the surface area of Riverpod provider access and makes dependencies explicit. The actual network call (getAttachmentUrl with useQueryAuth and customerKey) is unchanged.
Changed components
lib/pages/shopinbit/shopinbit_ticket_detail.dartInspect captured patch +9 / −12
diff --git a/lib/pages/shopinbit/shopinbit_ticket_detail.dart b/lib/pages/shopinbit/shopinbit_ticket_detail.dart
index 0057f36..a979ed8 100644
--- a/lib/pages/shopinbit/shopinbit_ticket_detail.dart
+++ b/lib/pages/shopinbit/shopinbit_ticket_detail.dart
@@ -826,12 +826,12 @@ class _AttachmentFileLink extends ConsumerWidget {
final String? filename;
final TextStyle textStyle;
- Future<void> _open(BuildContext context, WidgetRef ref) async {
+ Future<void> _open(BuildContext context, ShopInBitService service) async {
// Resolving the signed URL hits the token manager (and possibly the
// network), so show the loading overlay and surface any failure rather than
// doing nothing.
await showLoading<void>(
- whileFuture: _resolveAndLaunch(ref),
+ whileFuture: _resolveAndLaunch(service),
context: context,
message: "Opening attachment",
rootNavigator: Util.isDesktop,
@@ -846,15 +846,12 @@ class _AttachmentFileLink extends ConsumerWidget {
);
}
- Future<void> _resolveAndLaunch(WidgetRef ref) async {
- final resp = await ref
- .read(pShopinBitService)
- .client
- .getAttachmentUrl(
- proxyPath,
- useQueryAuth: true,
- customerKey: customerKey,
- );
+ Future<void> _resolveAndLaunch(ShopInBitService service) async {
+ final resp = await service.client.getAttachmentUrl(
+ proxyPath,
+ useQueryAuth: true,
+ customerKey: customerKey,
+ );
if (resp.hasError || resp.value == null) {
throw resp.exception ?? Exception("Could not resolve attachment URL");
}
@@ -881,7 +878,7 @@ class _AttachmentFileLink extends ConsumerWidget {
label: filename ?? 'attachment',
excludeSemantics: true,
child: GestureDetector(
- onTap: () => _open(context, ref),
+ onTap: () => _open(context, ref.read(pShopinBitService)),
child: Row(
mainAxisSize: MainAxisSize.min,
children: [
Why this scored 16/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.