You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(engine): keep a cloud-optimised GeoTIFF's look in a saved project - #1533
A cloud-optimised GeoTIFF tile layer saved by its plain web address loses its look. Saving cuts everything after # from a plain address, and that part holds #range=…, #bands=…, #dequantize=aef and, since #1339, #cube=1. The look is then counted in the notice for removed keys, passwords and (since #1521) URL fragments.
A data cube has this in url and in every time_urls entry. stac.addCube writes its fixed "range" there, so a reopened cube stretches each file on its own and the same value no longer draws the same grey from date to date.
A cube of one file has no time_urls, so #cube=1 is all that keeps it a tile layer. Reading the code, on main it is cut on saving and the layer opens as a raster.
AlphaEarth tiles (embeddings.add) lose their bands and stretch.
layer.addUrl of a plain COG is no longer affected: since #1339 it makes a raster layer, whose stretch is saved apart from its address.
Template and S3 connection addresses already kept their look; only the plain branch, now public_web_address in rustgis-data (#1521), dropped it.
Reproduced on main at 183ccdd3 (before #1521, which changed the notice's wording), saving map.addTiles of a public COG with #range=0,1000:
rustgis-cli: 1 layer address(es) were saved without their keys, tokens or passwords: after RustGIS closes, add those layers again to give them
"url":"https://sentinel-cogs.s3.us-west-2.amazonaws.com/sentinel-s2-l2a-cogs/36/Q/WD/2020/7/S2A_36QWD_20200701_0_L2A/TCI.tif"
With this PR the same commands give "stripped": 0, no such notice, and the address ends in TCI.tif#range=0,1000. Opened again, it is a raster layer stretched from 0 to 1000. With ?token=s3cret&v=1 before the look, the token goes, it is counted, and the address ends in TCI.tif?v=1#range=0,1000.
Changes
crates/engine/src/durable.rs, public_address_at: the plain branch takes the look off with split_look first, cleans the address with public_web_address as before, and puts the look back. An address with nothing else to remove now comes back unchanged, so it isn't counted and project.saveAs says nothing.
crates/engine/src/durable.rs, split_look (new, used by the plain, template and S3 connection branches): names what a saved look may hold: bands and range (which Look::parse has checked are numbers), dequantize as aef or none, cube as 0 or 1. Anything else isn't kept. Look::parse accepts any word for dequantize and cube, and a look is saved as written, so #dequantize=<anything> would otherwise reach the file. This also closes that gap in the template and S3 branches, which already kept looks as written. Reading is unchanged.
docs/user-guide/workspace.md: says a look is saved and any other # part isn't.
Choices in this proposal
Any other fragment still goes. OAuth and SAS-style links carry tokens after #, as sources::redact says, so only a look stays: band numbers, a range of two numbers, aef or none. #access_token=…, #range=0,1&token=… and #range=0,1?token=… are not looks. In #sig=…#range=0,1 only the last part stays.
The look is kept as written, not rewritten by Look::suffix. Rewriting would turn #range=0.0,1000.0 into #range=0,1000, the address would differ from the original, and it would be counted as a removed key.
What a saved look may hold is a closed list in split_look, not a change to Look::parse, so what a file saves changes and how an address is read doesn't. A key added to Look later isn't saved as written until it's named here: until then its look goes on saving, with the notice. RustGIS only ever writes aef and cube=1, and map.setTiles takes aef or none.
FORMAT stays at 1. A saved look is mostly nothing new to a reader: v0.4.0 and v0.5.0 read #range=…, #bands=… and #dequantize=aef through cog::split and draw them, and they already save looks on template and S3 connection addresses. v0.5.0 doesn't know cube, so it reads an address holding it as having no look at all, which is what it would get from that address saved on main. Saving again in those releases cuts the look and counts it in the "without their keys" notice, as they do today. Raising the version would make them refuse every project saved from now on, with or without a look, which seems too much for that. It's the maintainers' call.
Known limits
Projects already saved have lost their look. It can't be recovered from the file: add the layer or the cube again.
A hand-typed #range=0,1&dequantize=other still draws with its range in the open project, but its whole fragment goes when saved, range included, and is counted in the notice. RustGIS never writes such an address.
A project from this version opened and saved again in v0.4.0 or v0.5.0 loses its looks, with that notice, whose words don't fit a look.
A look-shaped fragment on an address that isn't a COG now stays too (a WMS address ending in #range=0,1, say). It holds only numbers and these words.
A fragment that isn't a look still goes and is counted, as on main.
sources::redact, used for the recent and saved sources lists, still drops every fragment, a look included. Its comment says nothing that adds a source needs it. Not changed here.
Testing
tests::layer_address_redaction_keeps_a_cogs_look (engine): looks kept on plain, s3://, anonymous, login-bound and template addresses; keys removed around a look; fragments that resemble a look removed, on template and S3 connection addresses too.
tests::saved_cubes_keep_their_look (engine): both ways through project.saveAs. A clean cube gives stripped 0, no notice, and opens with the same url and time_urls. A token on one date gives stripped 1 and the notice, the file holds no token but keeps the look, and the open project keeps everything. A cube of one file opens with its #cube=1, as a tile layer.
Both fail with durable.rs from main at c0da0d75 (on main the cube test reports stripped 3 where 0 is expected). With the closed list turned off (before fix(security): keep credentials within runtime boundaries #1521's move), the first failed on #dequantize=s3cret.
On Windows at 8af6da3d: the whole rustgis-engine lib suite passes, 845 tests with 5 ignored; cargo fmt and cargo clippy -p rustgis-engine --all-targets -D warnings pass. Before the merge of fix(security): keep credentials within runtime boundaries #1521, the rustgis-tiles, rustgis-map and rustgis-data lib tests passed too.
Earlier runs of the engine suite here were not clean, with or without this change: 1 to 5 tests failed per run, a different set each time, all passing alone (tile-cache and login tests sharing the process's state). One of them, a_cog_read_in_place_from_a_connection_records_it_and_follows_its_login, failed in 4 of 6 runs with this change and 0 of 4 without; it passed in the clean run above, doesn't save a project, and doesn't reach this code.
No visible change in the interface, so no screenshots.
Saved cloud-optimised GeoTIFF addresses now retain supported display settings, including band selection and range. Data cube fixed ranges are also saved.
Bug Fixes
Credentials and unrecognized URL fragments are excluded from saved addresses. Credentials can be restored when reopening the same saved project during the current session.
Documentation
Updated the workspace guide to explain which address settings are saved.
A plain web address lost everything after `#` when saved, so a COG lost its
`#range=…` and `#bands=…`, a data cube lost its fixed range on every date, and
saving counted each address as a removed key. Only a look stays: any other
fragment still goes, as OAuth and SAS-style links carry tokens there.
`dequantize` in a look now takes only `aef` or `none`, since a look is saved as
written and must not hold free text.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
No actionable comments were generated in the recent review.
Walkthrough
Address sanitization now separates supported COG looks from file components across archive, RustGIS S3, and web addresses. It removes credentials and unsupported fragments while retaining accepted looks. Tests cover saved-project behavior, and the workspace guide describes which fragments are retained.
Changes: Durable address sanitization
Layer / File(s)
Summary
Split, sanitize, and retain supported looks crates/engine/src/durable.rs, crates/engine/src/tests.rs, docs/user-guide/workspace.md
Address handling separates file components from looks before sanitization. It preserves accepted COG look parameters and removes other fragments. Tests cover credential removal, saved COG cube looks, and reopening a saved project. The workspace guide documents retained fragments.
opengeos/RustGIS#1405 — The change preserves supported look fragments when saved projects are resaved.
opengeos/RustGIS#757 — The change continues to remove sensitive URL keys while preserving supported looks in saved addresses.
Possibly related PRs
opengeos/RustGIS#1521 — This PR updates the durable address sanitization introduced there to retain supported COG looks.
opengeos/RustGIS#794 — This PR updates sanitization for RustGIS S3 addresses to preserve supported COG looks.
opengeos/RustGIS#1145 — This PR preserves supported looks while sanitizing saved login-bound addresses.
Suggested reviewers:mavrick-f, giswqs
Merge Risk: Minimal · up to 35545
The change preserves supported saved GeoTIFF looks while retaining address redaction. No actionable merge-blocking issue is established; merge after normal checks pass.
Pre-merge checks: 5
Check name
Status
Explanation
Title check
The title clearly describes the main change.
Description check
The description covers the change and testing. Add a UI evidence section with before-and-after screenshots of reopened layers. Add a Related issue section or state that none applies.
Docstring Coverage
Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Full details: Docstring Coverage
Explanation
Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 2 functions across 1 files. (2 skipped: 1 unsupported, 1 too large.)
Finishing Touches
Generate unit tests (beta)
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
A rabbit checks the map at night The saved look stays tucked in sight Credentials hop beyond the page Safe fragments rest inside the cage The workspace blooms in pixels bright
Recent review info
Run configuration
Source mode: Auto
Repository: Unavailable
Branch: Unavailable
File: No configuration file from this repository applied
Commit: Unavailable
Layers: Organization UI
Review profile: ASSERTIVE
Plan: Advanced
Run ID: 1018dacf-de15-404a-b836-5fbc9eddabfc
Commits
Reviewing files that changed from the base of the PR and between f8d5b0e and 355459a.
Files selected for processing: 3
crates/engine/src/durable.rs
crates/engine/src/tests.rs
docs/user-guide/workspace.md
Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.
I traced saved_address, split_look, cog::split and Look::parse by hand against each new test case, and checked the wrapper and template branches and the cache and embeddings callers. I could not compile or run the tests here (no shell), so the test results are unverified. Prior review threads: none, so no earlier concerns were left alone.
Bugs
crates/tiles/src/cog.rs:111 — Tightening dequantize also changes the reader. #range=0,1&dequantize=other used to apply its range and now is silently ignored, with no notice. AGENTS.md says a reader that drops data must say so. Medium confidence. Posted inline.
Security
No problems found. Kept look fragments can hold only band numbers, a finite range pair, or aef/none. Every test case I traced removes the keys and keeps the look as the PR says.
Low-confidence note: range= accepts any finite floats, so an all-digit secret placed under that key would be kept. The PR's "holds no free text" is true except for this.
Performance
None.
Quality
Nit: docs/user-guide/workspace.md lists #bands=… and #range=… but not &dequantize=aef, which is the AlphaEarth case the PR is about.
Nit: saved_cubes_keep_their_look calls remove_dir_all only at the end, so a failed assert leaves the temp directory behind.
Nit: in the wrapper branch, the look is appended after bind validates the length, so an address near MAX_ADDRESS could save as a wrapper that then fails to parse. Low confidence; the layer would fail visibly, not silently.
AGENTS.md
crates/engine/src/project.rs:100 — Saved files now carry looks that older RustGIS versions dropped. docs/maintaining.md says a format version goes up when an older reader would lose data, and FORMAT is still 1. Maintainer decision. Medium-low confidence. Posted inline.
Otherwise compliant: no new unwrap/panic, the stripped-count notice still applies to the cases that change, both clean and lossy cases are tested, and no dependencies changed.
Change size
Compared with the base branch (merge base 3c119b7 to PR head 159523b), the whole PR.
…reading
Tightening `Look::parse` also changed how an address is read: a hand-typed
`#range=0,1&dequantize=other` lost its range, unsaid. Reading stays as it was;
`split_look` now refuses to keep a look whose `dequantize` is another word.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
After opengeos#1339 a look also has `cube`, which takes any word as `dequantize` does.
`split_look` now names what may stay, so a key added later isn't saved as
written until it is named here. A one-file cube keeps its `#cube=1`, the only
thing that keeps it a tile layer when its project opens.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Left from the review summary above, for the release quality pass: the temp directory in saved_cubes_keep_their_look isn't removed when an assert fails, as in the tests around it. The note on the wrapper branch appending the look after bind checks the length is on code this PR doesn't change. The docs now list #dequantize=aef.
Verdict: no bugs, crash paths, or token leaks found. One low-to-medium concern about the notice wording, posted inline.
Bugs
None found. I traced the new split_look against cog::split and Look::parse. A fragment is kept only when Look::parse accepts the whole look and every key is a number or one of the allowed words. Otherwise the fragment is cut. Cases I checked: #range=0,1000?token=…, #dequantize=aef?token=…, #sig=…#range=…, the template, S3-wrapper and login-bound branches, and restore_addresses. Confidence: high.
Security
None found. Keys, tokens and signatures in a look are still removed. Any look value outside the closed list (bands, range, dequantize=aef|none, cube=0|1) is dropped with its whole fragment. Confidence: high.
Performance
None found. Confidence: high.
Quality
crates/engine/src/project.rs:114: when a look is rejected, the notice reports it as a lost key, token or password, even when the lost part is a range or band list. This is disclosed in the PR body and the new test pins the current wording. Confidence: low-medium. Posted inline.
AGENTS.md
The "Never silent" rule is only partly met by the wording above. Every other AGENTS.md point I checked is satisfied: no unwrap in non-test code, the tests cover both clean and lossy saves, and the docs change matches the behaviour.
Earlier review threads
Two threads already exist and both are resolved and answered by the author. I left both alone: the FORMAT version question, and the Look::parse reader change, which the author has reverted.
Change size
Compared with main (merge base 183ccdd to PR head 0bc424f).
opengeos#1521 moved saving addresses from `project.rs` to `durable.rs`. The look rule
moves with it: `public_address_at` keeps a look on a plain address too, and its
template and S3 branches use the same closed list.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bugs: None found. I traced split_look through cog::split (which splits at the last # and returns the whole address when Look::parse rejects the look), the pmtiles:/cog: and rustgis-s3: wrappers, and the plain web branch. Looks are kept only when Look::parse accepted them and the values are on the closed list. Anything else, including #range=0,1000?token=…, #dequantize=s3cret and #sig=…#range=…, is removed as before. I found no path where a token survives. I could not run the tests here (no shell), so this rests on reading the code and the test expectations.
Security: No leak found. One defence-in-depth point, inline on durable.rs:681: the bands/range arms accept any value and depend on Look::parse to have checked it. Confidence: low (it holds today).
Performance: Nothing notable. split_look does a small scan of the fragment.
Quality:
The PR body is stale. It places saved_address and split_look in project.rs, but the code is now in durable.rs (public_address_at and split_look). It also quotes the old notice wording; the head now reads "…without their keys, tokens, passwords or URL fragments". Confidence: high.
split_look returns (address, "") when it rejects a look, so the returned "file" then includes the rejected look. The doc comment doesn't say so, and the callers depend on it. Confidence: medium.
docs/user-guide/workspace.md lists #dequantize=aef, but the code also keeps dequantize=none and cube=0. Confidence: medium.
The new test leaves its temp directory behind if an assertion fails. Confidence: high, minor.
AGENTS.md: Tests are present for both the keep and the strip cases, and the notice path is covered. The three prior concerns were addressed by the author (the Look::parse revert, the version decision, and the notice wording, which the head has since changed). I left them alone.
Already raised, not re-posted (3): the Look::parse reader change, the FORMAT version question, and the notice wording for dropped looks. The version answer does not address the maintaining.md rule that a format version goes up when an older reader would "lose" data. I did not repeat it, but the maintainers may want to look at it.
On the latest summary: the PR text was updated for the move to durable.rs right after that review started, and it marks the quoted notice as main before #1521. Left for the release quality pass: the (address, "") return in split_look's doc comment, listing dequantize=none and cube=0 in the user guide (RustGIS never writes them), and the temp directory left by a failed assert.
Keeps main's reworded saving paragraph in docs/user-guide/workspace.md and
adds the COG look sentence after it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bugs: None found. I traced the new split_look against cog::split and Look::parse in crates/tiles/src/cog.rs. Each of these holds:
A look is kept only when every part is a known key with a value the reader accepts. bands and range are numeric-only, so a token cannot hide in them.
A look that fails the check goes with its fragment and is counted in the notice.
Recombination is correct in the plain, template (cog:/pmtiles:) and S3 branches. A rejected look stays in file, so the recursion strips it.
Every case in layer_address_redaction_keeps_a_cogs_look matches the code on a manual walk-through. The two new tests exercise the clean path and the lossy path.
Security: None found. Nothing outside the closed key list reaches the saved file, and whitespace around numbers cannot carry hidden content.
Performance: None. The new check is a constant-size split on a short suffix.
Quality:
Docs accuracy (low-medium confidence):docs/user-guide/workspace.md:46-47 scopes the kept look to COGs. The code keeps look-shaped fragments on any plain http(s)/s3 address, and the sentence omits #cube=1. Posted as an inline comment with suggested wording. It is a quality point, so it can go to the release quality pass.
Nit (not posted): the PR body says "RustGIS only ever writes aef and cube=1", but Look::suffix also writes bands and range. dequantize=none is accepted but never written. Both are harmless.
AGENTS.md: Compliant on the points I checked. The code has no unwrap/expect, it reports lossy saves through the existing notice, both lossy and clean paths are tested, and no new dependency is involved. I could not compile or run the tests here, since I have no shell. The PR says the engine suite passed on Windows.
Prior reviews: I left 4 earlier concerns alone, all already answered or marked outdated:
The bands/range defence-in-depth suggestion. I checked the author's answer and it holds: Look::parse rejects non-numbers for both keys.
The reader-behaviour change in cog.rs, which the author reverted.
The FORMAT version question, which the PR body addresses.
The notice wording for a rejected non-key look, which is deferred to the release quality pass.
Change size
Compared with the base branch: the whole PR against main (merge base f8d5b0e to PR head 355459a).
Peer ambiguity guard may be weakened (low-medium confidence). Before this PR a clean COG address with a look came back as Changed and was recorded in peer.rsrecord. It now comes back Unchanged and is skipped. Two slots that share a look, one with a token and one without, no longer make each other ambiguous, so the token-bearing slot can be restored when an incoming value matches its public form. Restoration is keyed by slot, so impact looks small. The PR's tests don't cover it. Posted inline at crates/engine/src/durable.rs:666 with a suggested peer test.
Security
No new issues. split_look only keeps bands/range (numeric, enforced by Look::parse), dequantize=aef|none, and cube=0|1. cog::split uses rsplit_once('#'), so a look that carries a ? or & token is rejected and stripped. I checked this against the new test cases.
Performance
No concerns. The extra split_look call runs only on address saving.
Quality
Left alone (already raised and answered in prior threads): the bands/range defence-in-depth check, the scope wording in workspace.md, and the notice wording for dropped looks.
Test evidence is cited at commit 8af6da3d, but the PR head is 355459a after merging main. Linux CI on the current head should be checked.
AGENTS.md
Re-raised as a summary note, not inline, because the prior thread is resolved. The format-version answer argues the cost of bumping FORMAT. It does not address the explicit "Never silent" rule that a file from a newer RustGIS is never saved again without what this version couldn't read. Under that rule, a v0.5.0 resave drops cube=1 with a notice. This is a maintainer decision (confidence medium-low).
Otherwise compliant: no unwrap/expect/panic in non-test code, get() is used, and the changed behaviour has both lossy and clean tests.
Already raised, left alone: 4 earlier concerns (the bands/range check, the workspace.md wording, the notice wording, and the format-version question, which I re-raised only as the note above).
Change size
Compared: the whole PR against main (merge base f8d5b0e to PR head 355459a).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Summary
A cloud-optimised GeoTIFF tile layer saved by its plain web address loses its look. Saving cuts everything after
#from a plain address, and that part holds#range=…,#bands=…,#dequantize=aefand, since #1339,#cube=1. The look is then counted in the notice for removed keys, passwords and (since #1521) URL fragments.urland in everytime_urlsentry.stac.addCubewrites its fixed"range"there, so a reopened cube stretches each file on its own and the same value no longer draws the same grey from date to date.time_urls, so#cube=1is all that keeps it a tile layer. Reading the code, onmainit is cut on saving and the layer opens as a raster.embeddings.add) lose their bands and stretch.map.addTilesopens as a raster since feat(raster): cloud-optimised GeoTIFFs are raster layers read in place #1339, without the look it was saved with.layer.addUrlof a plain COG is no longer affected: since #1339 it makes a raster layer, whose stretch is saved apart from its address.Template and S3 connection addresses already kept their look; only the plain branch, now
public_web_addressinrustgis-data(#1521), dropped it.Reproduced on
mainat183ccdd3(before #1521, which changed the notice's wording), savingmap.addTilesof a public COG with#range=0,1000:With this PR the same commands give
"stripped": 0, no such notice, and the address ends inTCI.tif#range=0,1000. Opened again, it is a raster layer stretched from 0 to 1000. With?token=s3cret&v=1before the look, the token goes, it is counted, and the address ends inTCI.tif?v=1#range=0,1000.Changes
crates/engine/src/durable.rs,public_address_at: the plain branch takes the look off withsplit_lookfirst, cleans the address withpublic_web_addressas before, and puts the look back. An address with nothing else to remove now comes back unchanged, so it isn't counted andproject.saveAssays nothing.crates/engine/src/durable.rs,split_look(new, used by the plain, template and S3 connection branches): names what a saved look may hold:bandsandrange(whichLook::parsehas checked are numbers),dequantizeasaefornone,cubeas0or1. Anything else isn't kept.Look::parseaccepts any word fordequantizeandcube, and a look is saved as written, so#dequantize=<anything>would otherwise reach the file. This also closes that gap in the template and S3 branches, which already kept looks as written. Reading is unchanged.docs/user-guide/workspace.md: says a look is saved and any other#part isn't.Choices in this proposal
#, assources::redactsays, so only a look stays: band numbers, a range of two numbers,aefornone.#access_token=…,#range=0,1&token=…and#range=0,1?token=…are not looks. In#sig=…#range=0,1only the last part stays.Look::suffix. Rewriting would turn#range=0.0,1000.0into#range=0,1000, the address would differ from the original, and it would be counted as a removed key.split_look, not a change toLook::parse, so what a file saves changes and how an address is read doesn't. A key added toLooklater isn't saved as written until it's named here: until then its look goes on saving, with the notice. RustGIS only ever writesaefandcube=1, andmap.setTilestakesaefornone.FORMATstays at 1. A saved look is mostly nothing new to a reader: v0.4.0 and v0.5.0 read#range=…,#bands=…and#dequantize=aefthroughcog::splitand draw them, and they already save looks on template and S3 connection addresses. v0.5.0 doesn't knowcube, so it reads an address holding it as having no look at all, which is what it would get from that address saved onmain. Saving again in those releases cuts the look and counts it in the "without their keys" notice, as they do today. Raising the version would make them refuse every project saved from now on, with or without a look, which seems too much for that. It's the maintainers' call.Known limits
#range=0,1&dequantize=otherstill draws with its range in the open project, but its whole fragment goes when saved, range included, and is counted in the notice. RustGIS never writes such an address.#range=0,1, say). It holds only numbers and these words.main.sources::redact, used for the recent and saved sources lists, still drops every fragment, a look included. Its comment says nothing that adds a source needs it. Not changed here.Testing
tests::layer_address_redaction_keeps_a_cogs_look(engine): looks kept on plain,s3://, anonymous, login-bound and template addresses; keys removed around a look; fragments that resemble a look removed, on template and S3 connection addresses too.tests::saved_cubes_keep_their_look(engine): both ways throughproject.saveAs. A clean cube givesstripped0, no notice, and opens with the sameurlandtime_urls. A token on one date givesstripped1 and the notice, the file holds no token but keeps the look, and the open project keeps everything. A cube of one file opens with its#cube=1, as a tile layer.durable.rsfrommainatc0da0d75(onmainthe cube test reportsstripped3 where 0 is expected). With the closed list turned off (before fix(security): keep credentials within runtime boundaries #1521's move), the first failed on#dequantize=s3cret.8af6da3d: the wholerustgis-enginelib suite passes, 845 tests with 5 ignored;cargo fmtandcargo clippy -p rustgis-engine --all-targets -D warningspass. Before the merge of fix(security): keep credentials within runtime boundaries #1521, therustgis-tiles,rustgis-mapandrustgis-datalib tests passed too.a_cog_read_in_place_from_a_connection_records_it_and_follows_its_login, failed in 4 of 6 runs with this change and 0 of 4 without; it passed in the clean run above, doesn't save a project, and doesn't reach this code.No visible change in the interface, so no screenshots.
🤖 Generated with Claude Code
Summary by CodeRabbit