add label generation api #498
Conversation
WalkthroughThis pull request introduces a comprehensive label maker feature for Homebox, enabling QR code generation and printing for locations, items, and assets. The implementation spans multiple components including backend configuration, API handlers, frontend components, and documentation. The changes add new routes, configuration options, and user interface elements to support label generation and printing functionality. Changes
Assessment against linked issues
Possibly related PRs
Suggested Labels
Suggested Reviewers
Security Recommendations
📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (17)
🚧 Files skipped from review as they are similar to previous changes (10)
🧰 Additional context used🪛 golangci-lint (1.62.2)backend/pkgs/labelmaker/labelmaker.go58-58: unnecessary conversion (unconvert) 145-145: unnecessary conversion (unconvert) 159-159: unnecessary conversion (unconvert) 1-1: ST1000: at least one file in a package should have a package comment (stylecheck) 34-34: ST1003: struct field Url should be URL (stylecheck) 🔇 Additional comments (8)
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments.
Actionable comments posted: 14
🔭 Outside diff range comments (1)
backend/app/api/static/docs/swagger.yaml (1)
Line range hint
1042-1044: Fix content-type mismatch in API specification.The endpoints are documented to produce "application/json" but return "image/jpeg". This should be corrected to:
produces: - ["application/json"] + ["image/jpeg"]Also applies to: 1081-1083, 1120-1122
🧹 Nitpick comments (8)
backend/pkgs/labelmaker/labelmaker.go (3)
1-1: Add a package-level comment for clarity and compliance with lint rules.Consider adding a brief comment describing what this package provides, aligning with Go's best practices.
🧰 Tools
🪛 golangci-lint (1.62.2)
1-1: ST1000: at least one file in a package should have a package comment
(stylecheck)
24-34: Use "URL" instead of "Url" to conform to Go naming conventions.Per Go style conventions (ST1003), all acronyms should be capitalized in exported identifiers.
- Url string + URL string🧰 Tools
🪛 golangci-lint (1.62.2)
34-34: ST1003: struct field Url should be URL
(stylecheck)
52-58: Avoid unnecessary conversions.The conversions at lines 58 and 145/159 in the static analysis indicate possibly redundant casting. Check and remove them if not strictly necessary.
🧰 Tools
🪛 golangci-lint (1.62.2)
58-58: unnecessary conversion
(unconvert)
backend/internal/sys/config/conf.go (2)
58-58: Rename the YAML tag to match the field name.Currently,
yaml:"string"might be unintentional. If you intended to label the field asprint_command, rename the tag accordingly.- PrintCommand *string `yaml:"string"` + PrintCommand *string `yaml:"print_command"`
21-29: Confirm that added config fields are properly documented.The new
LabelMakerfield inConfigshould be clearly documented, explaining each property within your configuration reference to help users configure label printing properly.frontend/components/global/LabelMaker.vue (1)
55-67: Add type safety to label type handling.The current implementation uses string literals for type checking. Consider using TypeScript enums or union types for better type safety.
+type LabelType = 'item' | 'location' | 'asset'; + function getLabelUrl(print: boolean): string { const params = { print }; - if (props.type === "item") { + if (props.type === ('item' as LabelType)) { return route(`/labelmaker/item/${props.id}`, params); - } else if (props.type === "location") { + } else if (props.type === ('location' as LabelType)) { return route(`/labelmaker/location/${props.id}`, params); - } else if (props.type === "asset") { + } else if (props.type === ('asset' as LabelType)) { return route(`/labelmaker/asset/${props.id}`, params); } else { throw new Error(`Unexpected labelmaker type ${props.type}`); } }backend/app/api/handlers/v1/controller.go (1)
134-134: Validate print command configuration before exposing status.The current implementation directly exposes the print command status without validation.
Add validation:
- LabelPrinting: ctrl.config.LabelMaker.PrintCommand != nil, + LabelPrinting: ctrl.config.LabelMaker.PrintCommand != nil && ctrl.validatePrintCommand(),Add this helper method to the controller:
func (ctrl *V1Controller) validatePrintCommand() bool { if ctrl.config.LabelMaker.PrintCommand == nil { return false } // Validate that the print command doesn't contain shell metacharacters return !strings.ContainsAny(*ctrl.config.LabelMaker.PrintCommand, "&|;<>$`\\") }backend/app/api/static/docs/swagger.json (1)
1057-1062: Improve print parameter specification.The print parameter's default value is mentioned in the description but not formally specified in the OpenAPI schema.
Add the default value to the schema for all three labelmaker endpoints:
{ "type": "boolean", "description": "Print this label, defaults to false", "name": "print", - "in": "query" + "in": "query", + "default": false }Also applies to: 1096-1101, 1135-1140
🛑 Comments failed to post (14)
backend/pkgs/labelmaker/labelmaker.go (1)
180-220:
⚠️ Potential issueSanitize external commands to prevent security vulnerabilities.
You are executing a command that may be influenced by user input in
PrintLabel. Ensure the command template is not susceptible to injection or arbitrary command execution. Consider validating or restricting user inputs or employing a safer approach (e.g., using well-known command line utilities with strict arguments).backend/app/api/handlers/v1/helpers.go (1)
20-30: 🛠️ Refactor suggestion
Validate URL parsing and usage to avoid potential security issues.
When stripping paths from a URL, carefully handle untrusted input to ensure maliciously crafted URLs do not cause unexpected behavior. Logging the error is good, but consider further validation if the URL is intended to be used in other critical operations.
backend/internal/sys/config/conf.go (1)
53-59:
⚠️ Potential issueSecurity recommendation: Provide safe defaults.
Since these settings directly affect label generation and printing, ensure the default configuration is safe and does not inadvertently allow remote code execution when specifying a
PrintCommand. Provide signs in documentation to remind users.frontend/components/global/LabelMaker.vue (1)
46-53:
⚠️ Potential issueEnhance security for file download implementation.
The current implementation of
downloadLabelcreates and manipulates DOM elements directly, which could pose security risks. Consider using theContent-Dispositionheader from the backend instead.Apply this diff to improve security:
function downloadLabel() { - const link = document.createElement("a"); - link.download = `label-${props.id}.jpg`; - link.href = getLabelUrl(false); - document.body.appendChild(link); - link.click(); - document.body.removeChild(link); + window.location.href = `${getLabelUrl(false)}&download=true`; }Committable suggestion skipped: line range outside the PR's diff.
backend/app/api/handlers/v1/v1_ctrl_labelmaker.go (3)
60-61:
⚠️ Potential issueSecurity: Avoid using Referer header for URL construction.
Using the Referer header for URL construction is unsafe as it can be spoofed or manipulated.
Consider using a configured base URL instead:
- hbUrl := GetHBURL(r.Header.Get("Referer"), ctrl.url) + hbUrl := ctrl.config.BaseURL return generateOrPrint(ctrl, w, r, location.Name, "Homebox Location", fmt.Sprintf("%s/location/%s", hbUrl, location.ID))Committable suggestion skipped: line range outside the PR's diff.
103-124: 🛠️ Refactor suggestion
Add security headers to prevent XSS and other attacks.
The handler should include security headers to protect against various web vulnerabilities.
Add these security headers at the beginning of the handler:
func (ctrl *V1Controller) HandleGetAssetLabel() errchain.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) error { + // Set security headers + w.Header().Set("X-Content-Type-Options", "nosniff") + w.Header().Set("X-Frame-Options", "DENY") + w.Header().Set("Content-Security-Policy", "default-src 'self'") + assetIDParam := chi.URLParam(r, "id")📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.func (ctrl *V1Controller) HandleGetAssetLabel() errchain.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) error { // Set security headers w.Header().Set("X-Content-Type-Options", "nosniff") w.Header().Set("X-Frame-Options", "DENY") w.Header().Set("Content-Security-Policy", "default-src 'self'") assetIDParam := chi.URLParam(r, "id") assetIDParam = strings.ReplaceAll(assetIDParam, "-", "") assetID, err := strconv.ParseInt(assetIDParam, 10, 64) if err != nil { return err } auth := services.NewContext(r.Context()) item, err := ctrl.repo.Items.QueryByAssetID(auth, auth.GID, repo.AssetID(assetID), 0, 1) if err != nil { return err } if len(item.Items) == 0 { return validate.NewRequestError(fmt.Errorf("failed to find asset id"), http.StatusNotFound) } hbUrl := GetHBURL(r.Header.Get("Referer"), ctrl.url) return generateOrPrint(ctrl, w, r, item.Items[0].AssetID.String(), fmt.Sprintf("%s\nHomebox Asset", item.Items[0].Name), fmt.Sprintf("%s/a/%s", hbUrl, item.Items[0].AssetID.String())) }
18-35:
⚠️ Potential issueEnhance security and error handling in generateOrPrint.
Several security and robustness improvements are needed:
- Missing content type headers
- No validation of configuration parameters
- Improper error handling for response writer
Apply these improvements:
func generateOrPrint(ctrl *V1Controller, w http.ResponseWriter, r *http.Request, title string, description string, url string) error { + // Validate configuration parameters + if ctrl.config.LabelMaker.Width <= 0 || ctrl.config.LabelMaker.Height <= 0 { + return validate.NewRequestError(fmt.Errorf("invalid label dimensions"), http.StatusInternalServerError) + } + params := labelmaker.NewGenerateParams(int(ctrl.config.LabelMaker.Width), int(ctrl.config.LabelMaker.Height), int(ctrl.config.LabelMaker.Padding), ctrl.config.LabelMaker.FontSize, title, description, url) print := queryBool(r.URL.Query().Get("print")) if print { err := labelmaker.PrintLabel(ctrl.config, ¶ms) if err != nil { return err } + w.Header().Set("Content-Type", "text/plain") w.Write([]byte("Printed!")) } else { + w.Header().Set("Content-Type", "image/jpeg") return labelmaker.GenerateLabel(w, ¶ms) } return nil }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.func generateOrPrint(ctrl *V1Controller, w http.ResponseWriter, r *http.Request, title string, description string, url string) error { // Validate configuration parameters if ctrl.config.LabelMaker.Width <= 0 || ctrl.config.LabelMaker.Height <= 0 { return validate.NewRequestError(fmt.Errorf("invalid label dimensions"), http.StatusInternalServerError) } params := labelmaker.NewGenerateParams(int(ctrl.config.LabelMaker.Width), int(ctrl.config.LabelMaker.Height), int(ctrl.config.LabelMaker.Padding), ctrl.config.LabelMaker.FontSize, title, description, url) print := queryBool(r.URL.Query().Get("print")) if print { err := labelmaker.PrintLabel(ctrl.config, ¶ms) if err != nil { return err } w.Header().Set("Content-Type", "text/plain") w.Write([]byte("Printed!")) } else { w.Header().Set("Content-Type", "image/jpeg") return labelmaker.GenerateLabel(w, ¶ms) } return nil }backend/app/api/routes.go (1)
165-168: 🛠️ Refactor suggestion
Add rate limiting to protect label generation endpoints.
Label generation endpoints could be resource-intensive. Consider adding rate limiting to prevent abuse.
Add rate limiting middleware:
+ // Labelmaker rate limiting middleware + labelMakerLimiter := middleware.NewRateLimit( + middleware.RateLimit{ + Window: 1 * time.Minute, + Limit: 10, + Strategy: "sliding-window", + }, + ) + // Labelmaker - r.Get("/labelmaker/location/{id}", chain.ToHandlerFunc(v1Ctrl.HandleGetLocationLabel(), userMW...)) - r.Get("/labelmaker/item/{id}", chain.ToHandlerFunc(v1Ctrl.HandleGetItemLabel(), userMW...)) - r.Get("/labelmaker/asset/{id}", chain.ToHandlerFunc(v1Ctrl.HandleGetAssetLabel(), userMW...)) + r.Get("/labelmaker/location/{id}", chain.ToHandlerFunc(v1Ctrl.HandleGetLocationLabel(), append(userMW, labelMakerLimiter)...)) + r.Get("/labelmaker/item/{id}", chain.ToHandlerFunc(v1Ctrl.HandleGetItemLabel(), append(userMW, labelMakerLimiter)...)) + r.Get("/labelmaker/asset/{id}", chain.ToHandlerFunc(v1Ctrl.HandleGetAssetLabel(), append(userMW, labelMakerLimiter)...))Committable suggestion skipped: line range outside the PR's diff.
backend/app/api/handlers/v1/v1_ctrl_items.go (1)
341-341: 💡 Codebase verification
🚨 Security: URL validation required in GetHBURL function
The current implementation directly uses the Referer header without any validation, which could lead to security vulnerabilities:
- Add URL validation to prevent malformed or malicious URLs
- Implement URL sanitization before usage
- Consider using
url.Parse()to validate URL structure- Add allowlist validation for expected domains
🔗 Analysis chain
Verify security implications of the new GetHBURL function.
The change from local
getHBURLto importedGetHBURLrequires security validation to prevent potential URL manipulation attacks.Run this script to analyze the implementation of
GetHBURL:🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check the implementation of GetHBURL for security concerns # Test: Look for URL validation and sanitization in the new implementation echo "Checking GetHBURL implementation..." ast-grep --pattern 'func GetHBURL($_, $_) $$$' backend/app/api/handlers/v1/helpers.go echo "Checking for URL validation..." rg -A 5 'GetHBURL' backend/app/api/handlers/v1/helpers.goLength of output: 424
backend/app/api/static/docs/docs.go (1)
1081-1119: 🛠️ Refactor suggestion
Implement rate limiting for label generation endpoints.
The new label generation endpoints could be resource-intensive. Consider implementing rate limiting to prevent DoS attacks.
Apply rate limiting middleware to these endpoints. Example implementation:
+ import "github.com/go-chi/httprate" func (app *App) routes() { + // Rate limit: 100 requests per minute + labelRateLimit := httprate.LimitByIP(100, 1*time.Minute) + app.router.With(labelRateLimit).Get("/v1/labelmaker/item/{id}", app.handleItemLabel) + app.router.With(labelRateLimit).Get("/v1/labelmaker/location/{id}", app.handleLocationLabel) + app.router.With(labelRateLimit).Get("/v1/labelmaker/assets/{id}", app.handleAssetLabel) }Also applies to: 1120-1158
docs/en/configure-homebox.md (1)
29-33: 🛠️ Refactor suggestion
Document security considerations for label maker configuration.
The new label maker configuration, especially
HBOX_LABEL_MAKER_PRINT_COMMAND, requires security documentation:
- Warn about command injection risks
- Provide secure configuration examples
Add security documentation:
| HBOX_LABEL_MAKER_PRINT_COMMAND | | the command to use for printing labels. if empty, label printing is disabled. `{{.FileName}}` in the command will be replaced with the jpg filename of the label | +| | | **Security Warning**: The print command is executed with the same privileges as the Homebox process. Ensure the command and its arguments are properly validated and sanitized to prevent command injection attacks. Example of secure configuration: `HBOX_LABEL_MAKER_PRINT_COMMAND="lp -d myprinter {{.FileName}}"` |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.| HBOX_LABEL_MAKER_WIDTH | 526 | width for generated labels in pixels | | HBOX_LABEL_MAKER_HEIGHT | 200 | height for generated labels in pixels | | HBOX_LABEL_MAKER_PADDING | 8 | padding between edges of label and around QR code in pixels | | HBOX_LABEL_MAKER_FONT_SIZE | 32.0 | the size of the labels font | | HBOX_LABEL_MAKER_PRINT_COMMAND | | the command to use for printing labels. if empty, label printing is disabled. `{{.FileName}}` in the command will be replaced with the jpg filename of the label | | | | **Security Warning**: The print command is executed with the same privileges as the Homebox process. Ensure the command and its arguments are properly validated and sanitized to prevent command injection attacks. Example of secure configuration: `HBOX_LABEL_MAKER_PRINT_COMMAND="lp -d myprinter {{.FileName}}"` |backend/app/api/static/docs/swagger.json (3)
1042-1044:
⚠️ Potential issueFix response content type inconsistency.
The endpoints are marked to produce "application/json" but the response is documented as "image/jpeg". Update the
producesfield to match the actual response type.Apply this change to all three labelmaker endpoints:
"produces": [ - "application/json" + "image/jpeg" ],Also applies to: 1081-1083, 1120-1122
1064-1071: 🛠️ Refactor suggestion
Document error responses for better API clarity.
The endpoints should document possible error responses for scenarios like:
- 401 Unauthorized: When the Bearer token is invalid or missing
- 404 Not Found: When the requested ID doesn't exist
- 500 Internal Server Error: For server-side errors
Add error responses to all three labelmaker endpoints. Example:
"responses": { "200": { "description": "image/jpeg", "schema": { "type": "string" } }, + "401": { + "description": "Unauthorized" + }, + "404": { + "description": "Not Found" + }, + "500": { + "description": "Internal Server Error" + } }Also applies to: 1103-1110, 1142-1149
1035-1151: 💡 Codebase verification
🔒 Security Controls Need Enhancement
The labelmaker endpoints require additional security measures:
- Add rate limiting middleware to prevent DoS through excessive label generation (e.g., max 10 requests per minute per user)
- Implement audit logging for label generation/printing activities
- Enhance input validation:
- Add length limits for IDs
- Implement strict format validation
- Sanitize all input parameters
- Consider adding request size limits to prevent memory exhaustion
Example middleware implementation:
func RateLimitLabels(next http.Handler) http.Handler { limiter := rate.NewLimiter(rate.Limit(10), 1) // 10 requests per minute return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { if !limiter.Allow() { http.Error(w, "Too many requests", http.StatusTooManyRequests) return } next.ServeHTTP(w, r) }) }🔗 Analysis chain
Security: Review authentication and authorization controls.
While the endpoints are secured with Bearer token authentication, consider these additional security measures:
- Rate limiting to prevent DoS attacks through excessive label generation
- Input validation for the ID parameter to prevent injection attacks
- Audit logging for label generation and printing activities
- Access control policies to restrict label generation to authorized users
Let's verify the implementation of these security controls:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for rate limiting middleware echo "Checking for rate limiting implementation..." rg -l "rate.*limit|throttle" --type go # Check for input validation echo "Checking for ID parameter validation..." rg -l "validate.*id|sanitize.*id" --type go # Check for audit logging echo "Checking for audit logging implementation..." rg -l "audit.*log|activity.*log" --type go # Check for access control echo "Checking for access control policies..." rg -l "authorize|permission|acl" --type goLength of output: 986
Script:
#!/bin/bash # Check labelmaker controller implementation echo "=== Labelmaker Controller ===" rg -A 10 "func.*GetAssetLabel|func.*GetItemLabel|func.*GetLocationLabel" backend/app/api/handlers/v1/v1_ctrl_labelmaker.go # Check middleware setup echo -e "\n=== Middleware Chain ===" rg -A 10 "func.*Setup.*Middleware|func.*Use.*Middleware" backend/app/api/middleware.go # Check for any request limiting patterns echo -e "\n=== Request Limiting Patterns ===" rg -A 5 "func.*Limit|max.*requests|max.*concurrent" backend/app/api/middleware.goLength of output: 1689
Script:
#!/bin/bash # Check authentication middleware echo "=== Authentication Implementation ===" rg -A 10 "func.*Authenticate|func.*Auth.*Middleware" backend/app/api/middleware.go backend/internal/web/mid/*.go # Check for global request controls in main setup echo -e "\n=== Global Controls ===" rg -A 5 "func.*main|func.*Setup|func.*Init" backend/app/api/main.go backend/cmd/**/main.goLength of output: 807
jake-walker
force-pushed
the
label-generation
branch
from
d7588c7 to
0d2e6db
Compare
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments.
Actionable comments posted: 4
🧹 Nitpick comments (5)
backend/pkgs/labelmaker/labelmaker.go (3)
1-1: Add a package-level comment.According to static analysis (stylecheck), at least one file in a package should have a package comment describing its purpose.
🧰 Tools
🪛 golangci-lint (1.62.2)
1-1: ST1000: at least one file in a package should have a package comment
(stylecheck)
34-34: Use consistent naming:URLvsUrl.Go naming conventions suggest using
URL(all caps) instead ofUrlfor struct fields and variables.- Url string + URL string🧰 Tools
🪛 golangci-lint (1.62.2)
34-34: ST1003: struct field Url should be URL
(stylecheck)
58-58: Avoid unnecessary conversions.Static analysis indicates unnecessary conversions at lines 58, 145, and 159.
- return int(ctx.PointToFixed(float64(width)).Round()) + return ctx.PointToFixed(float64(width)).Round()(similarly for lines 145 and 159, returning an int if indeed needed, or removing unnecessary type conversions.)
Also applies to: 145-145, 159-159
🧰 Tools
🪛 golangci-lint (1.62.2)
58-58: unnecessary conversion
(unconvert)
backend/app/api/handlers/v1/v1_ctrl_labelmaker.go (1)
18-35: Handle error statuses gracefully for advanced user feedback.Currently, errors in generating or printing labels are returned with minimal feedback to the client. Consider returning an HTTP status code that more clearly indicates the type of failure (e.g., 500 for server errors, 400 for client-side misconfiguration).
backend/app/api/handlers/v1/controller.go (1)
134-134: Consider conditional logic for labeling.When
LabelPrintingis toggled in the API summary, if printing is unexpectedly off but the user has a valid command, consider logging the state or clarifying to the user how to enable/disable it.
🛑 Comments failed to post (4)
backend/pkgs/labelmaker/labelmaker.go (1)
180-220:
⚠️ Potential issueConsider validating print command parameters akin to a security measure.
While printing commands are user-specified in configuration, it is prudent to log or validate them to ensure they’re from a trusted source. Failing to do so could lead to a command injection vulnerability if your environment is untrusted.
backend/app/api/static/docs/swagger.yaml (3)
1409-1480: 🛠️ Refactor suggestion
Add security headers for label endpoints.
For all three label endpoints, ensure proper security headers are set:
- Content-Security-Policy
- X-Content-Type-Options: nosniff
- X-Frame-Options: DENY
- Cache-Control headers for sensitive data
Apply these headers in the middleware or handler:
+ w.Header().Set("Content-Security-Policy", "default-src 'self'") + w.Header().Set("X-Content-Type-Options", "nosniff") + w.Header().Set("X-Frame-Options", "DENY") + w.Header().Set("Cache-Control", "no-store")Committable suggestion skipped: line range outside the PR's diff.
1433-1456: 💡 Codebase verification
Access controls are properly implemented with room for enhancement
The item label endpoint has robust security measures:
- Authentication via Bearer token
- Role-based access control via middleware
- Group-level authorization checks
- Input parameter validation
However, consider implementing rate limiting to prevent potential abuse of the label generation service.
🔗 Analysis chain
Verify access controls for item label generation.
Similar security considerations apply to the item label endpoint:
- Ensure proper access control checks
- Validate input parameters
- Consider adding rate limiting
Run this script to check for access control implementation:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if access control checks are implemented for item labels ast-grep --pattern 'func $_(.*) { $$$ if !hasPermission($_, $_) { $$$ } $$$ }'Length of output: 92
Script:
#!/bin/bash # Find the implementation file for the labelmaker item endpoint rg -l "labelmaker/item" --type-add 'code:*.{go,py,js,ts}' -t code # Also search for potential route definitions rg -l "func.*labelmaker.*item" --type-add 'code:*.{go,py,js,ts}' -t codeLength of output: 252
Script:
#!/bin/bash # Check the handler implementation cat backend/app/api/handlers/v1/v1_ctrl_labelmaker.go # Check routes for middleware cat backend/app/api/routes.goLength of output: 13505
1457-1480: 💡 Codebase verification
Access controls are properly implemented, but rate limiting is recommended
The location label endpoint has robust security measures:
- ✓ Bearer token authentication
- ✓ Role-based access control
- ✓ Input validation
- ✓ Group-scoped data access
However, consider implementing rate limiting to prevent potential abuse of the label generation service.
🔗 Analysis chain
Verify access controls for location label generation.
The location label endpoint needs similar security measures:
- Implement proper access control checks
- Validate location ID input
- Consider rate limiting
Run this script to check for access control implementation:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if access control checks are implemented for location labels ast-grep --pattern 'func $_(.*) { $$$ if !hasPermission($_, $_) { $$$ } $$$ }'Length of output: 92
Script:
#!/bin/bash # Find the implementation file and route registration rg -l "labelmaker/location/\{id\}" --type-add 'code:*.{go,py,js,ts}' -t code # Look for authentication middleware rg -l "Bearer" --type-add 'code:*.{go,py,js,ts}' -t code # Search for rate limiting implementations rg -l "RateLimit|rate.Limit|RateLimiter" --type-add 'code:*.{go,py,js,ts}' -t codeLength of output: 1191
Script:
#!/bin/bash # Check the label maker handler implementation cat backend/app/api/handlers/v1/v1_ctrl_labelmaker.go # Check middleware configuration cat backend/app/api/middleware.go # Check routes configuration cat backend/app/api/routes.goLength of output: 17560
This PR adds a label generator which can generate labels for items (either by ID or asset ID) and locations. In the config, a command can be set for printing labels out, the idea is that this would be you can pass the generated filename to a command that will print out the label. Alternatively, users can simply download the label through the UI to print another way.
This is just a draft for now as I'd like some feedback and still need to make this work nicely with the existing label generation "report" page.
Print confirmation modal
Location label
Item label
Asset label
What type of PR is this?
What this PR does / why we need it:
There are a bunch of people who want to be able to add labels to their physical Homebox locations, myself included, so this adds that functionality.
Which issue(s) this PR fixes:
Resolves #9 (now part of #436)
Special notes for your reviewer:
This is just a draft for now, I'm planning to give this a tidy up, and make sure it integrates nicely with the existing label generation page. In addition, I'd like to know any other issues I could potentially include (e.g. #495) or any feedback at all on this feature.
Testing
This has just been manually tested, but I can add tests if needed.
Summary by CodeRabbit
Based on the comprehensive pull request summary, here are the updated release notes:
New Features
Configuration
User Interface
API Enhancements
/labelmakerendpoints for generating labels.These changes expand Homebox's labeling capabilities, providing users with more flexible options for generating and managing item, location, and asset labels.