Found while sweeping for require_service_or_firebase_token siblings of server-26#81, not fixed in that session — deliberately left alone since trips is an intentional non-radio feature and the scope of #81 was incidents.py.
POST /trips/{trip_id}/chat (drb-c2-core/app/routers/trips.py, around line 515-563) is gated by require_service_or_firebase_token, same weak dependency #81 fixed on incidents.py. It calls gpt-4o-mini via AsyncOpenAI on every message, up to 6 tool-call iterations. Any authenticated Firebase user including role viewer can call it.
Unlike the incident summarize route, this one already has a deliberate mitigation: trip_chat_limiter.check(f"{caller_key}:{trip_id}") rate-limits by caller identity before the OpenAI call. That may be the intended and sufficient control for a general-utility chat feature (see trips-feature-intentional) rather than an oversight like #81 was.
Open question for a scoped decision, not an obvious bug: is the rate limiter alone acceptable exposure for a comped friends-and-family viewer account, or should this also gate on role (viewer vs operator/admin) the way incident summarize now does? Relevant to #50 (no spend cap on the comped tier) and #45 (Gate B5 7-day AI cost measurement) same as #81 was.
No code changed by this issue. Refs #81, #50, #45.
Found while sweeping for require_service_or_firebase_token siblings of server-26#81, not fixed in that session — deliberately left alone since trips is an intentional non-radio feature and the scope of #81 was incidents.py.
POST /trips/{trip_id}/chat (drb-c2-core/app/routers/trips.py, around line 515-563) is gated by require_service_or_firebase_token, same weak dependency #81 fixed on incidents.py. It calls gpt-4o-mini via AsyncOpenAI on every message, up to 6 tool-call iterations. Any authenticated Firebase user including role viewer can call it.
Unlike the incident summarize route, this one already has a deliberate mitigation: trip_chat_limiter.check(f"{caller_key}:{trip_id}") rate-limits by caller identity before the OpenAI call. That may be the intended and sufficient control for a general-utility chat feature (see trips-feature-intentional) rather than an oversight like #81 was.
Open question for a scoped decision, not an obvious bug: is the rate limiter alone acceptable exposure for a comped friends-and-family viewer account, or should this also gate on role (viewer vs operator/admin) the way incident summarize now does? Relevant to #50 (no spend cap on the comped tier) and #45 (Gate B5 7-day AI cost measurement) same as #81 was.
No code changed by this issue. Refs #81, #50, #45.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found while sweeping for require_service_or_firebase_token siblings of server-26#81, not fixed in that session — deliberately left alone since trips is an intentional non-radio feature and the scope of #81 was incidents.py.
POST /trips/{trip_id}/chat (drb-c2-core/app/routers/trips.py, around line 515-563) is gated by require_service_or_firebase_token, same weak dependency #81 fixed on incidents.py. It calls gpt-4o-mini via AsyncOpenAI on every message, up to 6 tool-call iterations. Any authenticated Firebase user including role viewer can call it.
Unlike the incident summarize route, this one already has a deliberate mitigation: trip_chat_limiter.check(f"{caller_key}:{trip_id}") rate-limits by caller identity before the OpenAI call. That may be the intended and sufficient control for a general-utility chat feature (see trips-feature-intentional) rather than an oversight like #81 was.
Open question for a scoped decision, not an obvious bug: is the rate limiter alone acceptable exposure for a comped friends-and-family viewer account, or should this also gate on role (viewer vs operator/admin) the way incident summarize now does? Relevant to #50 (no spend cap on the comped tier) and #45 (Gate B5 7-day AI cost measurement) same as #81 was.
No code changed by this issue. Refs #81, #50, #45.