New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: use encodeURIComponent to encode engineId #4371
Conversation
packages/renderer/src/routes.ts
Outdated
@@ -0,0 +1,21 @@ | |||
export class PodDetailsRoute { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello, I think we should not add code in src/ folder, as it's dedicated to Pods probably it can go as new method of the pod-utils
https://github.com/containers/podman-desktop/blob/main/packages/renderer/src/lib/pod/pod-utils.ts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My idea was to add new class/methods for each route defined in App.svelte
(at least the ones with parameters), which are not all related to pods, and have these methods at the same level of App.svelte
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say we need to split "code refactoring" and "fixes"
so do not try to change all routes of App.svelte and fix the encoding at the same time.
We need separate iteration/steps
one PR = one goal (can be refactoring (no-op) or bug fixes)
I don't see value in just adding a dedicated object just for routes as routes are specific to some area (like pods, containers, images, etc and we already have utility there)
in PodList we already have the object there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say we need to split "code refactoring" and "fixes"
You are right. I've created a new PR with the encoding fix only. I can work on the refactoring later, when I have a better idea of the source code.
packages/renderer/src/App.svelte
Outdated
<Route path="{PodDetailsRoute.path()}" breadcrumb="Pod Details" let:meta navigationHint="details"> | ||
<PodDetails | ||
podName="{decodeURI(meta.params.name)}" | ||
engineId="{decodeURI(meta.params.engineId)}" | ||
kind="{decodeURI(meta.params.kind)}" /> | ||
podName="{PodDetailsRoute.getName(meta.params)}" | ||
engineId="{PodDetailsRoute.getEngineId(meta.params)}" | ||
kind="{PodDetailsRoute.getKind(meta.params)}" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it will be easier to have a getRouteDetails on utility class and then just pass the argument
like
<Route path="podUtils.path" breadcrumb="Pod Details" let:meta navigationHint="details">
{@const routeDetails = podUtils.getRouteDetails(meta.params)}
<PodDetails
podName="{routeDetails.podName}"
engineId="{routeDetails.engineId}"
@@ -126,7 +127,15 @@ async function deleteSelectedPods() { | |||
} | |||
|
|||
function openDetailsPod(pod: PodInfoUI) { | |||
router.goto(`/pods/${encodeURI(pod.kind)}/${encodeURI(pod.name)}/${encodeURI(pod.engineId)}/logs`); | |||
const route = PodDetailsRoute.getRoute( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can ask podUtils object instead of adding a new PodDetailsRoute
also we can provide podInfoUi object to the method instead of providing each individual parameter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not want to make the (generic) Route methods coupled with the podInfoUi. For example in the following line, it would need to build such an podInfoUi object from the ContainerGroupInfoUI object and the podman
constant:
https://github.com/containers/podman-desktop/blob/main/packages/renderer/src/lib/ContainerList.svelte#L349
I would prefer to simply call it as:
PodDetailsRoute.getRoute({
kind: 'podman',
name: containerGroup.name,
engineId: containerGroup.engineId
})
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but you can have two methods, one with PodInfoUI and one with meta.params so it's convenient on client side
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the example you shown https://github.com/containers/podman-desktop/blob/main/packages/renderer/src/lib/ContainerList.svelte#L349-L351 you can provide containerGrou/ContainerGroupInfoUI object instead of building a new object
1e75594
to
771ef0b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hello @feloy could you add unit tests to check that we're fixing the problem
?
@benoitf I'm not sure how to test this. This involves the Route, which will analyze the passed But the Route is defined at the top level, in What do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@feloy I agree it might be difficult without a refactoring to test the current design of App.svelte as it's not so modular/delegating stuff (the decode part)
But we can I think test the part on encoding like on ContainerList, PodActions, PodDetailsLogs PodList to see if the router is correctly calling with the expected route
for example if we call in PodList the openDetails we can check the parameter on router.goto and see the behaviour with encodeURI vs encodeURIComponent
… to encode engineId Signed-off-by: Philippe Martin <phmartin@redhat.com> Signed-off-by: Philippe Martin <phmartin@redhat.com>
Signed-off-by: Philippe Martin <phmartin@redhat.com> Signed-off-by: Philippe Martin <phmartin@redhat.com>
This reverts commit 64a4028. Signed-off-by: Philippe Martin <phmartin@redhat.com>
…omponent to encode engineId" This reverts commit 9c2e239. Signed-off-by: Philippe Martin <phmartin@redhat.com>
OCP Sandobox provides an engineID with / characters, which are not encoded with encodeURI Signed-off-by: Philippe Martin <phmartin@redhat.com> Signed-off-by: Philippe Martin <phmartin@redhat.com>
771ef0b
to
915ad42
Compare
Signed-off-by: Philippe Martin <phmartin@redhat.com>
915ad42
to
c58e505
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @feloy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Tested, works fine 🚀
Signed-off-by: Philippe Martin phmartin@redhat.com
What does this PR do?
Screenshot/screencast of this PR
What issues does this PR fix or reference?
Fixes #3868
How to test this PR?
See steps in #3868