[jira] [Commented] (OFBIZ-11968) Error when rendering renderSubmitField macro
[
https://issues.apache.org/jira/browse/OFBIZ-11968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181817#comment-17181817
]
Dennis Balkir commented on OFBIZ-11968:
---
Hi Jacques,
yes I went there too.
The button in question was rendered for me like this:
{noformat}
{noformat}
> Error when rendering renderSubmitField macro
>
>
> Key: OFBIZ-11968
> URL: https://issues.apache.org/jira/browse/OFBIZ-11968
> Project: OFBiz
> Issue Type: Bug
> Components: framework/widget
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: James Yong
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: FindSkillsPageError.png, Image 001.png
>
>
> Error shown on page when accessing /humanres/control/FindPartySkills page
> {code:java}
> When calling macro "renderSubmitField", required parameter "id" (parameter
> #8) was not specified{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11968) Error when rendering renderSubmitField macro
[
https://issues.apache.org/jira/browse/OFBIZ-11968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181801#comment-17181801
]
Dennis Balkir commented on OFBIZ-11968:
---
Hi Jacques,
you are right, I simply over read the commit message and didn't realise the
changes were made and already commited.
I checked out the commit {{3c687a757c1085f49fda82fdbfe2e3af13b0e243}}, which is
the one you made with my changes, and tested again, getting the exact same
result as with my previous test:
{noformat}
{noformat}
I still am not able to reproduce this issue in my local version.
> Error when rendering renderSubmitField macro
>
>
> Key: OFBIZ-11968
> URL: https://issues.apache.org/jira/browse/OFBIZ-11968
> Project: OFBiz
> Issue Type: Bug
> Components: framework/widget
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: James Yong
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: FindSkillsPageError.png, Image 001.png
>
>
> Error shown on page when accessing /humanres/control/FindPartySkills page
> {code:java}
> When calling macro "renderSubmitField", required parameter "id" (parameter
> #8) was not specified{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11968) Error when rendering renderSubmitField macro
[
https://issues.apache.org/jira/browse/OFBIZ-11968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181768#comment-17181768
]
Dennis Balkir commented on OFBIZ-11968:
---
Hi Jacques and James,
I just pulled the trunk to be sure to have the current HEAD and started OFBiz
adding some test-field into my local PartyForms.xml to test this issue. For me,
this problem was not happening.
There is a good reason to it, which normally should not let this happen: in the
method, which gets the ID for such form-fields is an automated build-in, that
generates a unique ID for the field, if none is given, which seems to work fine
for me:
{noformat}
{noformat}
The ID will be created from the forms name and the fields name, in this case
being "LookupParty" and "test":
{noformat}
public String getIdName() {
if (UtilValidate.isNotEmpty(idName)) {
return idName;
}
String parentFormName = this.getParentFormName();
if (UtilValidate.isNotEmpty(parentFormName)) {
return parentFormName + "_" + this.getFieldName();
}
return this.modelForm.getName() + "_" + this.getFieldName();
}
{noformat}
The problem with adding a default like here to the ID, would be, that by adding
a default value, which would apply for all fields, would mean, that there would
be fields with equal IDs.
This defies the use of an ID, since by definition an HTML-ID has to be unique
on the page and can cause "trouble" if used incorrectly, which will result in
random behaviours of the page and elements reacting, when they should not.
I cannot guarantee to not have missed something, since you have some issues
with this, but I am not able to recreate the problem.
Can you provide some additional information on how this problem occurred for
you and what you did exactly to have these issues?
TIA
> Error when rendering renderSubmitField macro
>
>
> Key: OFBIZ-11968
> URL: https://issues.apache.org/jira/browse/OFBIZ-11968
> Project: OFBiz
> Issue Type: Bug
> Components: framework/widget
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: James Yong
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: FindSkillsPageError.png, Image 001.png
>
>
> Error shown on page when accessing /humanres/control/FindPartySkills page
> {code:java}
> When calling macro "renderSubmitField", required parameter "id" (parameter
> #8) was not specified{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11957) Form-Fields of certain types won't render IDs
[
https://issues.apache.org/jira/browse/OFBIZ-11957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181147#comment-17181147
]
Dennis Balkir commented on OFBIZ-11957:
---
Hi Jacques,
I am a little confused now. You described what page you would open but did you
add an ID to some of the fields? I actually added a field with the attribute
"id-name" to the field I was testing this with.
About the Freemarker Issue: If I understand correctly, there are more instances
of this same problem in different places, and they have all to be fixed,
correct?
Sorry for my confusion here
> Form-Fields of certain types won't render IDs
> -
>
> Key: OFBIZ-11957
> URL: https://issues.apache.org/jira/browse/OFBIZ-11957
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Dennis Balkir
>Priority: Minor
>
> While implementing some OFBiz-Forms, I noticed, that certain types of
> form-fields will not render the set ID.
> Field-Types that won't work for sure are {{submit}} and {{hyperlink}} where
> the set name for the parameter {{id-name}} simply will not be rendered in the
> HTML-Code that is generetad by OFBiz.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11957) Form-Fields of certain types won't render IDs
[
https://issues.apache.org/jira/browse/OFBIZ-11957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181041#comment-17181041
]
Dennis Balkir edited comment on OFBIZ-11957 at 8/20/20, 8:48 AM:
-
Hi Jacques,
actually PR227 includes all the changes that I made in the previous PR and the
missing line, as I mentioned before.
I tested it on the branch that I provided for the pull request by adding a
submit field with an id to the first form in {{PartyForms.xml}} and it worked
for me (means the id got rendered in the HTML code).
Wouldn't it be better to make a new issue for other kinds of fields, since I
just made this issue for form fields and it could be kind of confusing if we
start to add other changes to it now.
bq. Also trivial just for syntax consistency, you should better use id="" in
renderSubmitField "signature", like in for
bq. title="" name="" event="" confirmation="" containerId="" tabindex=""
I did not do it like this, because as you can see in the macro, most of the
field do not have this kind of declaration and since ID is not really a
necessary field for HTML-elements and HAS to be unique for it to work, it would
be a really bad idea to give it a default value.
{noformat}
<#macro renderSubmitField buttonType className alert formName action imgSrc
ajaxUrl id title="" name="" event="" confirmation="" containerId="" tabindex="">
{noformat}
was (Author: dennis balkir):
Hi Jacques,
actually PR227 includes all the changes that I made in the previous PR and the
missing line, as I mentioned before.
I tested it on the branch that I provided for the pull request by adding a
submit field with an id to the first form in {{PartyForms.xml}} and it worked
for me (means the id got rendered in the HTML code).
Wouldn't it be better to make a new issue for other kinds of fields, since I
just made this issue for form fields and it could be kind of confusing if we
start to add other changes to it now.
bq. Also trivial just for syntax consistency, you should better use id="" in
renderSubmitField "signature", like in for
bq.
bq. title="" name="" event="" confirmation="" containerId="" tabindex=""
I did not do it like this, because as you can see in the macro, most of the
field do not have this kind of declaration and since ID is not really a
necessary field for HTML-elements and HAS to be unique for it to work, it would
be a really bad idea to give it a default value.
{noformat}
<#macro renderSubmitField buttonType className alert formName action imgSrc
ajaxUrl id title="" name="" event="" confirmation="" containerId="" tabindex="">
{noformat}
> Form-Fields of certain types won't render IDs
> -
>
> Key: OFBIZ-11957
> URL: https://issues.apache.org/jira/browse/OFBIZ-11957
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Dennis Balkir
>Priority: Minor
>
> While implementing some OFBiz-Forms, I noticed, that certain types of
> form-fields will not render the set ID.
> Field-Types that won't work for sure are {{submit}} and {{hyperlink}} where
> the set name for the parameter {{id-name}} simply will not be rendered in the
> HTML-Code that is generetad by OFBiz.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11957) Form-Fields of certain types won't render IDs
[
https://issues.apache.org/jira/browse/OFBIZ-11957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17181041#comment-17181041
]
Dennis Balkir commented on OFBIZ-11957:
---
Hi Jacques,
actually PR227 includes all the changes that I made in the previous PR and the
missing line, as I mentioned before.
I tested it on the branch that I provided for the pull request by adding a
submit field with an id to the first form in {{PartyForms.xml}} and it worked
for me (means the id got rendered in the HTML code).
Wouldn't it be better to make a new issue for other kinds of fields, since I
just made this issue for form fields and it could be kind of confusing if we
start to add other changes to it now.
bq. Also trivial just for syntax consistency, you should better use id="" in
renderSubmitField "signature", like in for
bq.
bq. title="" name="" event="" confirmation="" containerId="" tabindex=""
I did not do it like this, because as you can see in the macro, most of the
field do not have this kind of declaration and since ID is not really a
necessary field for HTML-elements and HAS to be unique for it to work, it would
be a really bad idea to give it a default value.
{noformat}
<#macro renderSubmitField buttonType className alert formName action imgSrc
ajaxUrl id title="" name="" event="" confirmation="" containerId="" tabindex="">
{noformat}
> Form-Fields of certain types won't render IDs
> -
>
> Key: OFBIZ-11957
> URL: https://issues.apache.org/jira/browse/OFBIZ-11957
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Dennis Balkir
>Priority: Minor
>
> While implementing some OFBiz-Forms, I noticed, that certain types of
> form-fields will not render the set ID.
> Field-Types that won't work for sure are {{submit}} and {{hyperlink}} where
> the set name for the parameter {{id-name}} simply will not be rendered in the
> HTML-Code that is generetad by OFBiz.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11957) Form-Fields of certain types won't render IDs
[
https://issues.apache.org/jira/browse/OFBIZ-11957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180606#comment-17180606
]
Dennis Balkir commented on OFBIZ-11957:
---
I made a new pull request this time with the missing line in it. This time I
tested it again before making the commit and it worked for me:
https://github.com/apache/ofbiz-framework/pull/227
> Form-Fields of certain types won't render IDs
> -
>
> Key: OFBIZ-11957
> URL: https://issues.apache.org/jira/browse/OFBIZ-11957
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Dennis Balkir
>Priority: Minor
>
> While implementing some OFBiz-Forms, I noticed, that certain types of
> form-fields will not render the set ID.
> Field-Types that won't work for sure are {{submit}} and {{hyperlink}} where
> the set name for the parameter {{id-name}} simply will not be rendered in the
> HTML-Code that is generetad by OFBiz.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11957) Form-Fields of certain types won't render IDs
[
https://issues.apache.org/jira/browse/OFBIZ-11957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180560#comment-17180560
]
Dennis Balkir commented on OFBIZ-11957:
---
I will add this missing piec and make a new pull request for that
> Form-Fields of certain types won't render IDs
> -
>
> Key: OFBIZ-11957
> URL: https://issues.apache.org/jira/browse/OFBIZ-11957
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Dennis Balkir
>Priority: Minor
>
> While implementing some OFBiz-Forms, I noticed, that certain types of
> form-fields will not render the set ID.
> Field-Types that won't work for sure are {{submit}} and {{hyperlink}} where
> the set name for the parameter {{id-name}} simply will not be rendered in the
> HTML-Code that is generetad by OFBiz.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11957) Form-Fields of certain types won't render IDs
[
https://issues.apache.org/jira/browse/OFBIZ-11957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180554#comment-17180554
]
Dennis Balkir edited comment on OFBIZ-11957 at 8/19/20, 1:36 PM:
-
You are right, somehow my added ID field in the {{renderSubmitField}}
declaration is missing in this.
These lines (I made a patch previously for this, to not loose some of my
changes) are missing:
{noformat}
-<#macro renderSubmitField buttonType className alert formName action imgSrc
ajaxUrl title="" name="" event="" confirmation="" containerId="" tabindex="">
+<#macro renderSubmitField buttonType className alert formName action imgSrc
ajaxUrl id title="" name="" event="" confirmation="" containerId=""
tabindex="">{noformat}
The other change in this file {{HtmlFormMacroLibrary.ftl}} has made it's way in
my pull request. I am sorry for the inconvinience
was (Author: dennis balkir):
You are right, somehow my added ID field in the {{renderSubmitField}}
declaration is missing in this.
These lines (I made a patch previously for this, to not loose some of my
changes) are missing:
{noformat}
-<#macro renderSubmitField buttonType className alert formName action imgSrc
ajaxUrl title="" name="" event="" confirmation="" containerId="" tabindex="">
+<#macro renderSubmitField buttonType className alert formName action imgSrc
ajaxUrl id title="" name="" event="" confirmation="" containerId=""
tabindex="">{noformat}
> Form-Fields of certain types won't render IDs
> -
>
> Key: OFBIZ-11957
> URL: https://issues.apache.org/jira/browse/OFBIZ-11957
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Dennis Balkir
>Priority: Minor
>
> While implementing some OFBiz-Forms, I noticed, that certain types of
> form-fields will not render the set ID.
> Field-Types that won't work for sure are {{submit}} and {{hyperlink}} where
> the set name for the parameter {{id-name}} simply will not be rendered in the
> HTML-Code that is generetad by OFBiz.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11957) Form-Fields of certain types won't render IDs
[
https://issues.apache.org/jira/browse/OFBIZ-11957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180554#comment-17180554
]
Dennis Balkir commented on OFBIZ-11957:
---
You are right, somehow my added ID field in the {{renderSubmitField}}
declaration is missing in this.
These lines (I made a patch previously for this, to not loose some of my
changes) are missing:
{noformat}
-<#macro renderSubmitField buttonType className alert formName action imgSrc
ajaxUrl title="" name="" event="" confirmation="" containerId="" tabindex="">
+<#macro renderSubmitField buttonType className alert formName action imgSrc
ajaxUrl id title="" name="" event="" confirmation="" containerId=""
tabindex="">{noformat}
> Form-Fields of certain types won't render IDs
> -
>
> Key: OFBIZ-11957
> URL: https://issues.apache.org/jira/browse/OFBIZ-11957
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Dennis Balkir
>Priority: Minor
>
> While implementing some OFBiz-Forms, I noticed, that certain types of
> form-fields will not render the set ID.
> Field-Types that won't work for sure are {{submit}} and {{hyperlink}} where
> the set name for the parameter {{id-name}} simply will not be rendered in the
> HTML-Code that is generetad by OFBiz.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11957) Form-Fields of certain types won't render IDs
[
https://issues.apache.org/jira/browse/OFBIZ-11957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180505#comment-17180505
]
Dennis Balkir commented on OFBIZ-11957:
---
Hi Jacques,
I just tried it in OFBiz 12 or 13 (not sure actually, it was an old customers
project and it was reproductible there too.
My guess is, that this was simply not implemented when this function was build.
> Form-Fields of certain types won't render IDs
> -
>
> Key: OFBIZ-11957
> URL: https://issues.apache.org/jira/browse/OFBIZ-11957
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Assignee: Dennis Balkir
>Priority: Minor
>
> While implementing some OFBiz-Forms, I noticed, that certain types of
> form-fields will not render the set ID.
> Field-Types that won't work for sure are {{submit}} and {{hyperlink}} where
> the set name for the parameter {{id-name}} simply will not be rendered in the
> HTML-Code that is generetad by OFBiz.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11877) Convert testCreateAndUpdateContactList test from XML to Groovy
[
https://issues.apache.org/jira/browse/OFBIZ-11877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17180489#comment-17180489
]
Dennis Balkir commented on OFBIZ-11877:
---
Hello [~jleroux],
I actuall got an error out of this change:
{{The declared package
"applications.marketing.src.main.groovy.org.apache.ofbiz.marketing" does not
match the expected package "org.apache.ofbiz.marketing"}}
The declared package looks weird to me too. Can you take a look at this?
> Convert testCreateAndUpdateContactList test from XML to Groovy
> --
>
> Key: OFBIZ-11877
> URL: https://issues.apache.org/jira/browse/OFBIZ-11877
> Project: OFBiz
> Issue Type: Sub-task
> Components: marketing
>Affects Versions: Trunk
>Reporter: Akash Jain
>Assignee: Pawan Verma
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-11877.patch
>
>
> Convert testCreateAndUpdateContactList test from XML to Groovy.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OFBIZ-11957) Form-Fields of certain types won't render IDs
Dennis Balkir created OFBIZ-11957:
-
Summary: Form-Fields of certain types won't render IDs
Key: OFBIZ-11957
URL: https://issues.apache.org/jira/browse/OFBIZ-11957
Project: OFBiz
Issue Type: Improvement
Affects Versions: Trunk
Reporter: Dennis Balkir
Assignee: Dennis Balkir
While implementing some OFBiz-Forms, I noticed, that certain types of
form-fields will not render the set ID.
Field-Types that won't work for sure are {{submit}} and {{hyperlink}} where the
set name for the parameter {{id-name}} simply will not be rendered in the
HTML-Code that is generetad by OFBiz.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11448) Potential Nullpointer in ErrorPage.ftl
[
https://issues.apache.org/jira/browse/OFBIZ-11448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056024#comment-17056024
]
Dennis Balkir commented on OFBIZ-11448:
---
The patch is provided here: [https://github.com/apache/ofbiz-framework/pull/47]
as a pull request
> Potential Nullpointer in ErrorPage.ftl
> --
>
> Key: OFBIZ-11448
> URL: https://issues.apache.org/jira/browse/OFBIZ-11448
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This line of code right here:
> {code:java}
> ${request.getAttribute("_ERROR_MESSAGE_")?replace("\n", "")}
> {code}
> can produce a nullpointer error, since the attribute "_ERROR_MESSAGE_" from
> the request ist used by the replace method of freemarker, without
> nullchecking it first.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OFBIZ-11448) Potential Nullpointer in ErrorPage.ftl
Dennis Balkir created OFBIZ-11448:
-
Summary: Potential Nullpointer in ErrorPage.ftl
Key: OFBIZ-11448
URL: https://issues.apache.org/jira/browse/OFBIZ-11448
Project: OFBiz
Issue Type: Bug
Affects Versions: Trunk
Reporter: Dennis Balkir
This line of code right here:
{code:java}
${request.getAttribute("_ERROR_MESSAGE_")?replace("\n", "")}
{code}
can produce a nullpointer error, since the attribute "_ERROR_MESSAGE_" from the
request ist used by the replace method of freemarker, without nullchecking it
first.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-10587) _WARNING_MESSAGE_
[ https://issues.apache.org/jira/browse/OFBIZ-10587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055981#comment-17055981 ] Dennis Balkir commented on OFBIZ-10587: --- The patch is provided as a pull request > _WARNING_MESSAGE_ > - > > Key: OFBIZ-10587 > URL: https://issues.apache.org/jira/browse/OFBIZ-10587 > Project: OFBiz > Issue Type: Wish > Components: ALL COMPONENTS >Reporter: Niklas Fallik >Assignee: Michael Brohl >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Hi there, > I am looking for a way to display warning messages. We are using > EVENT_MESSAGE and ERROR_MESSAGE which we can pass to the frontend to display > to the user, but it turned out that it would be nice to have a type for > warnings like WARNING_MESSAGE. > I figured out that the java classes ServiceEventHandler and > ScriptEventHandler deal with those message types. > I really would appreciate if anyone already had a solution for this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OFBIZ-11305) Remove unnecessary header-row classes in Upcoming.ftl
Dennis Balkir created OFBIZ-11305:
-
Summary: Remove unnecessary header-row classes in Upcoming.ftl
Key: OFBIZ-11305
URL: https://issues.apache.org/jira/browse/OFBIZ-11305
Project: OFBiz
Issue Type: Improvement
Components: workeffort
Affects Versions: Trunk
Reporter: Dennis Balkir
Attachments: OFBIZ-11305 - UpcomingFTL.patch
There are some table rows in the template {{Upcoming.ftl}} that are always
created with the class {{header-row}}.
This is not really a problem, except that it doesn't make any real sense. This
class is normally used for actual table header-rows, but these wring table rows
are created between any upcoming events in this table.
Since this class is has no real use here but instead is used wrong here, I
removed it from the inner table rows.
It doesn't affect the looks of the table in any theme in a negative way, since
there are line elemtens in between each calendar entry.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11305) Remove unnecessary header-row classes in Upcoming.ftl
[
https://issues.apache.org/jira/browse/OFBIZ-11305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-11305:
--
Attachment: OFBIZ-11305 - UpcomingFTL.patch
> Remove unnecessary header-row classes in Upcoming.ftl
> -
>
> Key: OFBIZ-11305
> URL: https://issues.apache.org/jira/browse/OFBIZ-11305
> Project: OFBiz
> Issue Type: Improvement
> Components: workeffort
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-11305 - UpcomingFTL.patch
>
>
> There are some table rows in the template {{Upcoming.ftl}} that are always
> created with the class {{header-row}}.
> This is not really a problem, except that it doesn't make any real sense.
> This class is normally used for actual table header-rows, but these wring
> table rows are created between any upcoming events in this table.
> Since this class is has no real use here but instead is used wrong here, I
> removed it from the inner table rows.
> It doesn't affect the looks of the table in any theme in a negative way,
> since there are line elemtens in between each calendar entry.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-10187) OWASP sanitizer breaks proper rendering of HTML code
[
https://issues.apache.org/jira/browse/OFBIZ-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841370#comment-16841370
]
Dennis Balkir commented on OFBIZ-10187:
---
Hi Jacques,
you are right, these are missing in my version.
I checked it and it seems, that the ebay version on github was changed on 25th
march this year, so it might be possible, that the missing components just
weren't in this file as I used it as a template for my changes.
I didn't add them myself, because I thought, that they are not important enough
to put them inside of an OFBiz policy opposing to the ones I added, which are
quite important for current development with HTML 5.
> OWASP sanitizer breaks proper rendering of HTML code
>
>
> Key: OFBIZ-10187
> URL: https://issues.apache.org/jira/browse/OFBIZ-10187
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, 16.11.04, Release Branch 17.12, Release Branch
> 18.12
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Critical
> Labels: backport-needed
> Fix For: 17.12.01, 16.11.06, 18.12.01
>
> Attachments:
> OFBIZ-10187_Rewrite-CustomPermissivePolicy-matchesEithe.patch,
> OFBIZ-10187_Sanitizer.patch, OFBIZ-10187_Sanitizer_16.11.patch,
> OFBIZ-10187_Sanitizer_New.patch
>
>
> The current implementation of the sanitizer breaks the proper rendering of
> html code. In our case, class attributes are stripped from the html content.
> Example:
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> will be rendered to
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> I do not see any reason to not allow class attributes in html code. There
> might be other problems with these rules but this is a showstopper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10187) OWASP sanitizer breaks proper rendering of HTML code
[
https://issues.apache.org/jira/browse/OFBIZ-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841172#comment-16841172
]
Dennis Balkir edited comment on OFBIZ-10187 at 5/16/19 9:54 AM:
Hi Jacques,
sorry for my late response, but I thought that you solved this for you after
you wrote this comment.
{quote}Mmm, finally it's not as deprecated as I thought. Because [I looked at a
fork|https://github.com/andresriancho/owaspantisamy] when I look at what I
think it's the original I see it's maintained:
[https://github.com/nahsra/antisamy]
[https://github.com/nahsra/antisamy/issues/10]
Still we are actually using [https://github.com/OWASP/java-html-sanitizer]
which is clearly well maintianed, and turning to antisamy does not seem to be
better for us.
{quote}
I actually got this CustomPolicy Class from the github project that you linked
in one of your first comments:
{quote}I don't remember all about prepackaged policies from the top of my head
and when looking for references from
[https://github.com/OWASP/java-html-sanitizer] I got this
{quote}
This is the example class featured in the project:
[https://github.com/OWASP/java-html-sanitizer/blob/master/src/main/java/org/owasp/html/examples/EbayPolicyExample.java]
I just added some important things that were missing and were not violateble
with cross scripting, including some HTML 5 elements, since they were not at
all featured in this example.
I hope this helps, if there are any more questions, feel free to ask.
was (Author: dennis balkir):
Hi Jacques,
sorry for my late response, but I thought that you solved this for you after
you wrote this comment.
{quote}Mmm, finally it's not as deprecated as I thought. Because [I looked at a
fork|https://github.com/andresriancho/owaspantisamy] when I look at what I
think it's the original I see it's maintained:
[https://github.com/nahsra/antisamy]
[https://github.com/nahsra/antisamy/issues/10]
Still we are actually using [https://github.com/OWASP/java-html-sanitizer]
which is clearly well maintianed, and turning to antisamy does not seem to be
better for us.
{quote}
I actuall got this CustomPolicy Class from the github project that you linked
in one of your first comments:
{quote}I don't remember all about prepackaged policies from the top of my head
and when looking for references from
[https://github.com/OWASP/java-html-sanitizer] I got this
{quote}
This is the example class featured in the project:
[https://github.com/OWASP/java-html-sanitizer/blob/master/src/main/java/org/owasp/html/examples/EbayPolicyExample.java]
I just added some important things that were missing and were not violateble
with cross scripting, including some HTML 5 elements, since they were not at
all featured in this example.
I hope this helps, if there are any more questions, feel free to ask.
> OWASP sanitizer breaks proper rendering of HTML code
>
>
> Key: OFBIZ-10187
> URL: https://issues.apache.org/jira/browse/OFBIZ-10187
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, 16.11.04, Release Branch 17.12, Release Branch
> 18.12
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Critical
> Labels: backport-needed
> Fix For: 17.12.01, 16.11.06, 18.12.01
>
> Attachments:
> OFBIZ-10187_Rewrite-CustomPermissivePolicy-matchesEithe.patch,
> OFBIZ-10187_Sanitizer.patch, OFBIZ-10187_Sanitizer_16.11.patch,
> OFBIZ-10187_Sanitizer_New.patch
>
>
> The current implementation of the sanitizer breaks the proper rendering of
> html code. In our case, class attributes are stripped from the html content.
> Example:
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> will be rendered to
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet,
[jira] [Commented] (OFBIZ-10187) OWASP sanitizer breaks proper rendering of HTML code
[
https://issues.apache.org/jira/browse/OFBIZ-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841172#comment-16841172
]
Dennis Balkir commented on OFBIZ-10187:
---
Hi Jacques,
sorry for my late response, but I thought that you solved this for you after
you wrote this comment.
{quote}Mmm, finally it's not as deprecated as I thought. Because [I looked at a
fork|https://github.com/andresriancho/owaspantisamy] when I look at what I
think it's the original I see it's maintained:
[https://github.com/nahsra/antisamy]
[https://github.com/nahsra/antisamy/issues/10]
Still we are actually using [https://github.com/OWASP/java-html-sanitizer]
which is clearly well maintianed, and turning to antisamy does not seem to be
better for us.
{quote}
I actuall got this CustomPolicy Class from the github project that you linked
in one of your first comments:
{quote}I don't remember all about prepackaged policies from the top of my head
and when looking for references from
[https://github.com/OWASP/java-html-sanitizer] I got this
{quote}
This is the example class featured in the project:
[https://github.com/OWASP/java-html-sanitizer/blob/master/src/main/java/org/owasp/html/examples/EbayPolicyExample.java]
I just added some important things that were missing and were not violateble
with cross scripting, including some HTML 5 elements, since they were not at
all featured in this example.
I hope this helps, if there are any more questions, feel free to ask.
> OWASP sanitizer breaks proper rendering of HTML code
>
>
> Key: OFBIZ-10187
> URL: https://issues.apache.org/jira/browse/OFBIZ-10187
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: Trunk, 16.11.04, Release Branch 17.12, Release Branch
> 18.12
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Critical
> Labels: backport-needed
> Fix For: 17.12.01, 16.11.06, 18.12.01
>
> Attachments:
> OFBIZ-10187_Rewrite-CustomPermissivePolicy-matchesEithe.patch,
> OFBIZ-10187_Sanitizer.patch, OFBIZ-10187_Sanitizer_16.11.patch,
> OFBIZ-10187_Sanitizer_New.patch
>
>
> The current implementation of the sanitizer breaks the proper rendering of
> html code. In our case, class attributes are stripped from the html content.
> Example:
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> will be rendered to
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> I do not see any reason to not allow class attributes in html code. There
> might be other problems with these rules but this is a showstopper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10925) Wrong permission check in ProductScreens#FindProduct
[
https://issues.apache.org/jira/browse/OFBIZ-10925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818101#comment-16818101
]
Dennis Balkir commented on OFBIZ-10925:
---
I just removed the permission service completely.
There was the service {{productGenericPermission}} which could have been used
instead, but this one calls the simple-method
{{checkProductRelatedPermission}}, which then check for the {{CATALOG}}
permisson. Since this is already done in the {{CommonProductDecorator}} before,
it would not make any sense to do this a sceond time.
> Wrong permission check in ProductScreens#FindProduct
>
>
> Key: OFBIZ-10925
> URL: https://issues.apache.org/jira/browse/OFBIZ-10925
> Project: OFBiz
> Issue Type: Bug
> Components: product
>Reporter: Dennis Balkir
>Priority: Major
> Attachments: OFBIZ-10925_ProductScreens.patch
>
>
> The permisson service {{acctgAgreementPermissionCheck}} is used in the screen
> {{FindProduct}} in {{ProductScreens.xml}}. This doesn't really make sense,
> since there is no connection to the accounting application here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10925) Wrong permission check in ProductScreens#FindProduct
[
https://issues.apache.org/jira/browse/OFBIZ-10925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-10925:
--
Attachment: OFBIZ-10925_ProductScreens.patch
> Wrong permission check in ProductScreens#FindProduct
>
>
> Key: OFBIZ-10925
> URL: https://issues.apache.org/jira/browse/OFBIZ-10925
> Project: OFBiz
> Issue Type: Bug
> Components: product
>Reporter: Dennis Balkir
>Priority: Major
> Attachments: OFBIZ-10925_ProductScreens.patch
>
>
> The permisson service {{acctgAgreementPermissionCheck}} is used in the screen
> {{FindProduct}} in {{ProductScreens.xml}}. This doesn't really make sense,
> since there is no connection to the accounting application here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OFBIZ-10925) Wrong permission check in ProductScreens#FindProduct
Dennis Balkir created OFBIZ-10925:
-
Summary: Wrong permission check in ProductScreens#FindProduct
Key: OFBIZ-10925
URL: https://issues.apache.org/jira/browse/OFBIZ-10925
Project: OFBiz
Issue Type: Bug
Components: product
Reporter: Dennis Balkir
The permisson service {{acctgAgreementPermissionCheck}} is used in the screen
{{FindProduct}} in {{ProductScreens.xml}}. This doesn't really make sense,
since there is no connection to the accounting application here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10187) OWASP sanitizer breaks proper rendering of HTML code
[
https://issues.apache.org/jira/browse/OFBIZ-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-10187:
--
Attachment: OFBIZ-10187_Sanitizer_New.patch
> OWASP sanitizer breaks proper rendering of HTML code
>
>
> Key: OFBIZ-10187
> URL: https://issues.apache.org/jira/browse/OFBIZ-10187
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: 16.11.04
>Reporter: Michael Brohl
>Assignee: Dennis Balkir
>Priority: Critical
> Attachments: OFBIZ-10187_Sanitizer.patch,
> OFBIZ-10187_Sanitizer_New.patch
>
>
> The current implementation of the sanitizer breaks the proper rendering of
> html code. In our case, class attributes are stripped from the html content.
> Example:
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> will be rendered to
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> I do not see any reason to not allow class attributes in html code. There
> might be other problems with these rules but this is a showstopper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10187) OWASP sanitizer breaks proper rendering of HTML code
[
https://issues.apache.org/jira/browse/OFBIZ-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807639#comment-16807639
]
Dennis Balkir commented on OFBIZ-10187:
---
Hi Michael and Jacques,
I added a new patch, which is not that different, but includes a few HTML 5
specific elements inside of the custom policy.
This will provide at least some HTML 5 compability.
> OWASP sanitizer breaks proper rendering of HTML code
>
>
> Key: OFBIZ-10187
> URL: https://issues.apache.org/jira/browse/OFBIZ-10187
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: 16.11.04
>Reporter: Michael Brohl
>Assignee: Dennis Balkir
>Priority: Critical
> Attachments: OFBIZ-10187_Sanitizer.patch,
> OFBIZ-10187_Sanitizer_New.patch
>
>
> The current implementation of the sanitizer breaks the proper rendering of
> html code. In our case, class attributes are stripped from the html content.
> Example:
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> will be rendered to
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> I do not see any reason to not allow class attributes in html code. There
> might be other problems with these rules but this is a showstopper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10187) OWASP sanitizer breaks proper rendering of HTML code
[
https://issues.apache.org/jira/browse/OFBIZ-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806865#comment-16806865
]
Dennis Balkir commented on OFBIZ-10187:
---
Hi Jacques and Michael,
it has been some time since this patch was provided and I simply wanted to make
sure, that it won't be forgotten.
Thanks!
PS: I didn't mean to assign that issue to me, I just seemed to press a wrong
button.
> OWASP sanitizer breaks proper rendering of HTML code
>
>
> Key: OFBIZ-10187
> URL: https://issues.apache.org/jira/browse/OFBIZ-10187
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: 16.11.04
>Reporter: Michael Brohl
>Assignee: Dennis Balkir
>Priority: Critical
> Attachments: OFBIZ-10187_Sanitizer.patch
>
>
> The current implementation of the sanitizer breaks the proper rendering of
> html code. In our case, class attributes are stripped from the html content.
> Example:
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> will be rendered to
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> I do not see any reason to not allow class attributes in html code. There
> might be other problems with these rules but this is a showstopper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OFBIZ-10187) OWASP sanitizer breaks proper rendering of HTML code
[
https://issues.apache.org/jira/browse/OFBIZ-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir reassigned OFBIZ-10187:
-
Assignee: Dennis Balkir (was: Michael Brohl)
> OWASP sanitizer breaks proper rendering of HTML code
>
>
> Key: OFBIZ-10187
> URL: https://issues.apache.org/jira/browse/OFBIZ-10187
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: 16.11.04
>Reporter: Michael Brohl
>Assignee: Dennis Balkir
>Priority: Critical
> Attachments: OFBIZ-10187_Sanitizer.patch
>
>
> The current implementation of the sanitizer breaks the proper rendering of
> html code. In our case, class attributes are stripped from the html content.
> Example:
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> will be rendered to
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> I do not see any reason to not allow class attributes in html code. There
> might be other problems with these rules but this is a showstopper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10187) OWASP sanitizer breaks proper rendering of HTML code
[
https://issues.apache.org/jira/browse/OFBIZ-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16787012#comment-16787012
]
Dennis Balkir commented on OFBIZ-10187:
---
Hi Jacques, Michael,
since this is something I stumbled upon while working on a project, I took my
time to implement a fix to this.
I added some funtionality and made the whole sanitizing process more
customizable this way.
This is the way it works:
* There is now a properties {{sanitizer.enable}}, which I added to
owasp.properties, that can turn on or off the whole sanitizing process
* I changed the existing property {{sanitizer.permissive.policy}} from boolean
use to text use
* With {{sanitizer.permissive.policy=CUSTOM}} it is now possible to use a
customized policy, which then replaces the {{PERMISSIVE_POLICY}}
** I implemented an Interface, which is the base for the custom policy
** There is another property {{sanitizer.custom.policy.class}} in which a class
path can be specified
** The sanitize method will get the class for the path from the property and
will check if it implements the mentioned interface
** When the class implements the interface, a method {{getSanitizerPolicy()}}
is used and will return the specified policy of the custom class
** When failing, the default {{PERMISSIVE_POLICY}} is used as a fallback
I also added a class {{CustomPermissivePolicy}} which can be used as an example
for this customizing process.
There also should be no invulnerable policies in there, so it should be safe to
use, even without changing it at all.
It also features many attributed and elements that the current
{{PERMISSIVE_POLICY}} is missing.
> OWASP sanitizer breaks proper rendering of HTML code
>
>
> Key: OFBIZ-10187
> URL: https://issues.apache.org/jira/browse/OFBIZ-10187
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: 16.11.04
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Critical
> Attachments: OFBIZ-10187_Sanitizer.patch
>
>
> The current implementation of the sanitizer breaks the proper rendering of
> html code. In our case, class attributes are stripped from the html content.
> Example:
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> will be rendered to
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> I do not see any reason to not allow class attributes in html code. There
> might be other problems with these rules but this is a showstopper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10187) OWASP sanitizer breaks proper rendering of HTML code
[
https://issues.apache.org/jira/browse/OFBIZ-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-10187:
--
Attachment: OFBIZ-10187_Sanitizer.patch
> OWASP sanitizer breaks proper rendering of HTML code
>
>
> Key: OFBIZ-10187
> URL: https://issues.apache.org/jira/browse/OFBIZ-10187
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
>Affects Versions: 16.11.04
>Reporter: Michael Brohl
>Assignee: Michael Brohl
>Priority: Critical
> Attachments: OFBIZ-10187_Sanitizer.patch
>
>
> The current implementation of the sanitizer breaks the proper rendering of
> html code. In our case, class attributes are stripped from the html content.
> Example:
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> will be rendered to
> {code:java}
>
> src="<@ofbizContentUrl>/webcontent/img/slider/1.jpg"
> alt="" />
>
>
> Lorem ipsum dolor sit amet
> At vero eos et accusam et justo
>
> Lorem ipsum dolor sit amet, consetetur
> sadipscing elitr, dolores et ea rebum. Stet clita kasd gubergren, no sea
> takimata sanctus est Lorem ipsum dolor sit amet.
>
> href="<@ofbizUrl>cms/~webpage_id=100">weitere Informationen
>
>
> {code}
> I do not see any reason to not allow class attributes in html code. There
> might be other problems with these rules but this is a showstopper.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10823) Removing "Competitors & Partners" and "Documents" from SFA
[ https://issues.apache.org/jira/browse/OFBIZ-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754818#comment-16754818 ] Dennis Balkir commented on OFBIZ-10823: --- Hi [~pfm.smits], of course, you are right. I just didn't think about that for a moment :D > Removing "Competitors & Partners" and "Documents" from SFA > -- > > Key: OFBIZ-10823 > URL: https://issues.apache.org/jira/browse/OFBIZ-10823 > Project: OFBiz > Issue Type: Improvement > Components: marketing >Affects Versions: Trunk >Reporter: Dennis Balkir >Priority: Minor > Attachments: OFBIZ-10823_SfaMenus.patch > > > There are two dead menu items, namely "Competitors & Partners" and > "Documents", which can be found in SFA. > Some years ago, some people started development for this feature, as seen > here OFBIZ-2364, but it was never finished. > After some quick research, it seemed like nothing got patched into OFBiz > either. > I asked via the developer mailinglist, if there were any objections against > removing the menu items and since there were no complains, I will provide a > patch in here to remove them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10823) Removing "Competitors & Partners" and "Documents" from SFA
[ https://issues.apache.org/jira/browse/OFBIZ-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-10823: -- Attachment: OFBIZ-10823_SfaMenus.patch > Removing "Competitors & Partners" and "Documents" from SFA > -- > > Key: OFBIZ-10823 > URL: https://issues.apache.org/jira/browse/OFBIZ-10823 > Project: OFBiz > Issue Type: Improvement > Components: marketing >Affects Versions: Trunk >Reporter: Dennis Balkir >Priority: Minor > Attachments: OFBIZ-10823_SfaMenus.patch > > > There are two dead menu items, namely "Competitors & Partners" and > "Documents", which can be found in SFA. > Some years ago, some people started development for this feature, as seen > here OFBIZ-2364, but it was never finished. > After some quick research, it seemed like nothing got patched into OFBiz > either. > I asked via the developer mailinglist, if there were any objections against > removing the menu items and since there were no complains, I will provide a > patch in here to remove them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10823) Removing "Competitors & Partners" and "Documents" from SFA
[ https://issues.apache.org/jira/browse/OFBIZ-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-10823: -- Attachment: (was: OFBIZ-10823_SfaMenus.patch) > Removing "Competitors & Partners" and "Documents" from SFA > -- > > Key: OFBIZ-10823 > URL: https://issues.apache.org/jira/browse/OFBIZ-10823 > Project: OFBiz > Issue Type: Improvement > Components: marketing >Affects Versions: Trunk >Reporter: Dennis Balkir >Priority: Minor > Attachments: OFBIZ-10823_SfaMenus.patch > > > There are two dead menu items, namely "Competitors & Partners" and > "Documents", which can be found in SFA. > Some years ago, some people started development for this feature, as seen > here OFBIZ-2364, but it was never finished. > After some quick research, it seemed like nothing got patched into OFBiz > either. > I asked via the developer mailinglist, if there were any objections against > removing the menu items and since there were no complains, I will provide a > patch in here to remove them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10823) Removing "Competitors & Partners" and "Documents" from SFA
[ https://issues.apache.org/jira/browse/OFBIZ-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-10823: -- Attachment: OFBIZ-10823_SfaMenus.patch > Removing "Competitors & Partners" and "Documents" from SFA > -- > > Key: OFBIZ-10823 > URL: https://issues.apache.org/jira/browse/OFBIZ-10823 > Project: OFBiz > Issue Type: Improvement > Components: marketing >Affects Versions: Trunk >Reporter: Dennis Balkir >Priority: Minor > Attachments: OFBIZ-10823_SfaMenus.patch > > > There are two dead menu items, namely "Competitors & Partners" and > "Documents", which can be found in SFA. > Some years ago, some people started development for this feature, as seen > here OFBIZ-2364, but it was never finished. > After some quick research, it seemed like nothing got patched into OFBiz > either. > I asked via the developer mailinglist, if there were any objections against > removing the menu items and since there were no complains, I will provide a > patch in here to remove them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-2364) Competitors & Partners - Sales Force Automation component
[ https://issues.apache.org/jira/browse/OFBIZ-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754737#comment-16754737 ] Dennis Balkir commented on OFBIZ-2364: -- Since there were no complains in the mailinglist, I opened OFBIZ-10823 to remove the dead menu items. > Competitors & Partners - Sales Force Automation component > - > > Key: OFBIZ-2364 > URL: https://issues.apache.org/jira/browse/OFBIZ-2364 > Project: OFBiz > Issue Type: New Feature > Components: marketing >Affects Versions: Trunk > Environment: Mac OS X >Reporter: Vikas Mayur >Priority: Minor > Attachments: SFA Competitors & Partners.patch > > > Competitors and Partners will be parties (generally PartyGroup) and are > related to other items including Accounts, Opportunities, and so on. > The screens for Competitor would include: Competitor Home, Accounts, > Opportunities. > The screens for Partner would include: Partner Home, Accounts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10823) Removing "Competitors & Partners" and "Documents" from SFA
[ https://issues.apache.org/jira/browse/OFBIZ-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-10823: -- Description: There are two dead menu items, namely "Competitors & Partners" and "Documents", which can be found in SFA. Some years ago, some people started development for this feature, as seen here OFBIZ-2364, but it was never finished. After some quick research, it seemed like nothing got patched into OFBiz either. I asked via the developer mailinglist, if there were any objections against removing the menu items and since there were no complains, I will provide a patch in here to remove them. was: There are two dead menu items, namely "Competitors & Partners" and "Documents", which can be found in SFA. Some years ago, some people started development for this feature, as seen here OFBiz-2364, but it was never finished. After some quick research, it seemed like nothing got patched into OFBiz either. I asked via the developer mailinglist, if there were any objections against removing the menu items and since there were no complains, I will provide a patch in here to remove them. > Removing "Competitors & Partners" and "Documents" from SFA > -- > > Key: OFBIZ-10823 > URL: https://issues.apache.org/jira/browse/OFBIZ-10823 > Project: OFBiz > Issue Type: Improvement > Components: marketing >Affects Versions: Trunk >Reporter: Dennis Balkir >Priority: Minor > > There are two dead menu items, namely "Competitors & Partners" and > "Documents", which can be found in SFA. > Some years ago, some people started development for this feature, as seen > here OFBIZ-2364, but it was never finished. > After some quick research, it seemed like nothing got patched into OFBiz > either. > I asked via the developer mailinglist, if there were any objections against > removing the menu items and since there were no complains, I will provide a > patch in here to remove them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-10823) Removing "Competitors & Partners" and "Documents" from SFA
Dennis Balkir created OFBIZ-10823: - Summary: Removing "Competitors & Partners" and "Documents" from SFA Key: OFBIZ-10823 URL: https://issues.apache.org/jira/browse/OFBIZ-10823 Project: OFBiz Issue Type: Improvement Components: marketing Affects Versions: Trunk Reporter: Dennis Balkir There are two dead menu items, namely "Competitors & Partners" and "Documents", which can be found in SFA. Some years ago, some people started development for this feature, as seen here OFBiz-2364, but it was never finished. After some quick research, it seemed like nothing got patched into OFBiz either. I asked via the developer mailinglist, if there were any objections against removing the menu items and since there were no complains, I will provide a patch in here to remove them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-2364) Competitors & Partners - Sales Force Automation component
[ https://issues.apache.org/jira/browse/OFBIZ-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743238#comment-16743238 ] Dennis Balkir commented on OFBIZ-2364: -- Hi [~jacques.le.roux], I think it is safe to say, that there won't be any more development in this feature. The suggestion would be to remove the menu points "Competitors & Partners" and "Documents" since they are both undefined links in the SfaMenus.xml and for this serve no further porpuse. > Competitors & Partners - Sales Force Automation component > - > > Key: OFBIZ-2364 > URL: https://issues.apache.org/jira/browse/OFBIZ-2364 > Project: OFBiz > Issue Type: New Feature > Components: marketing >Affects Versions: Trunk > Environment: Mac OS X >Reporter: Vikas Mayur >Priority: Minor > Attachments: SFA Competitors & Partners.patch > > > Competitors and Partners will be parties (generally PartyGroup) and are > related to other items including Accounts, Opportunities, and so on. > The screens for Competitor would include: Competitor Home, Accounts, > Opportunities. > The screens for Partner would include: Partner Home, Accounts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10813) Improve Accounting -> Financial Account container structure
[ https://issues.apache.org/jira/browse/OFBIZ-10813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743218#comment-16743218 ] Dennis Balkir commented on OFBIZ-10813: --- The patch I added treats this structural difference like it was done in Accounting AR and Accounting AP. The changes also work with all past themes, too. > Improve Accounting -> Financial Account container structure > --- > > Key: OFBIZ-10813 > URL: https://issues.apache.org/jira/browse/OFBIZ-10813 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Affects Versions: Trunk >Reporter: Dennis Balkir >Priority: Minor > Attachments: OFBIZ-10813_FinAccountScreens.patch > > > There were again some structural differences found, this time in Accounting > -> Financial Account. > I treated them like I did Accounting AR -> Main in > https://issues.apache.org/jira/browse/OFBIZ-10469 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-10813) Improve Accounting -> Financial Account container structure
Dennis Balkir created OFBIZ-10813: - Summary: Improve Accounting -> Financial Account container structure Key: OFBIZ-10813 URL: https://issues.apache.org/jira/browse/OFBIZ-10813 Project: OFBiz Issue Type: Improvement Components: accounting Affects Versions: Trunk Reporter: Dennis Balkir Attachments: OFBIZ-10813_FinAccountScreens.patch There were again some structural differences found, this time in Accounting -> Financial Account. I treated them like I did Accounting AR -> Main in https://issues.apache.org/jira/browse/OFBIZ-10469 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10813) Improve Accounting -> Financial Account container structure
[ https://issues.apache.org/jira/browse/OFBIZ-10813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-10813: -- Attachment: OFBIZ-10813_FinAccountScreens.patch > Improve Accounting -> Financial Account container structure > --- > > Key: OFBIZ-10813 > URL: https://issues.apache.org/jira/browse/OFBIZ-10813 > Project: OFBiz > Issue Type: Improvement > Components: accounting >Affects Versions: Trunk >Reporter: Dennis Balkir >Priority: Minor > Attachments: OFBIZ-10813_FinAccountScreens.patch > > > There were again some structural differences found, this time in Accounting > -> Financial Account. > I treated them like I did Accounting AR -> Main in > https://issues.apache.org/jira/browse/OFBIZ-10469 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10476) Fix / Remove Compdoc?
[ https://issues.apache.org/jira/browse/OFBIZ-10476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742244#comment-16742244 ] Dennis Balkir commented on OFBIZ-10476: --- I added a patch, which removes everything of the CompDoc funcionality that I could find. I also did run the tests, and there was nothing failing. The other functions of content seem to work fine too. > Fix / Remove Compdoc? > - > > Key: OFBIZ-10476 > URL: https://issues.apache.org/jira/browse/OFBIZ-10476 > Project: OFBiz > Issue Type: Bug > Components: content >Reporter: Dennis Balkir >Assignee: Michael Brohl >Priority: Major > Attachments: OFBIZ-10476_Content-CompDoc.patch > > > While creating a theme and looking for not correctly styled elements I came > across "some" not functional links and buttons in Compdoc. > This module seems not to be finished or working properly, because most of the > times, the buttons inside the appbar produce errors or just empty pages. > Even when searching for existing elements and then clicking on them to > examine or edit them will mostly create an error (example: go to compdoc, > search for template child, click edit on some random found element -> error). > Sometimes the menu which is included inside the appbar, mostly the menu > called "tree", need the contentId for the buttons to work. > Including this menu while creating a new entry will result in every button > not working and throwing an error, except the edit button, which will produce > a completely empty page. > Those things appear all over the module, trying some button or clicking some > link resulted in an error screen more than it resulted in something actually > working. > This should either be fixed or removed, if this doesn't has a real purpose at > all. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10476) Fix / Remove Compdoc?
[ https://issues.apache.org/jira/browse/OFBIZ-10476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-10476: -- Attachment: OFBIZ-10476_Content-CompDoc.patch > Fix / Remove Compdoc? > - > > Key: OFBIZ-10476 > URL: https://issues.apache.org/jira/browse/OFBIZ-10476 > Project: OFBiz > Issue Type: Bug > Components: content >Reporter: Dennis Balkir >Assignee: Michael Brohl >Priority: Major > Attachments: OFBIZ-10476_Content-CompDoc.patch > > > While creating a theme and looking for not correctly styled elements I came > across "some" not functional links and buttons in Compdoc. > This module seems not to be finished or working properly, because most of the > times, the buttons inside the appbar produce errors or just empty pages. > Even when searching for existing elements and then clicking on them to > examine or edit them will mostly create an error (example: go to compdoc, > search for template child, click edit on some random found element -> error). > Sometimes the menu which is included inside the appbar, mostly the menu > called "tree", need the contentId for the buttons to work. > Including this menu while creating a new entry will result in every button > not working and throwing an error, except the edit button, which will produce > a completely empty page. > Those things appear all over the module, trying some button or clicking some > link resulted in an error screen more than it resulted in something actually > working. > This should either be fixed or removed, if this doesn't has a real purpose at > all. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10476) Fix / Remove Compdoc?
[ https://issues.apache.org/jira/browse/OFBIZ-10476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739614#comment-16739614 ] Dennis Balkir commented on OFBIZ-10476: --- I will provide a patch for this asap, thanks > Fix / Remove Compdoc? > - > > Key: OFBIZ-10476 > URL: https://issues.apache.org/jira/browse/OFBIZ-10476 > Project: OFBiz > Issue Type: Bug > Components: content >Reporter: Dennis Balkir >Assignee: Michael Brohl >Priority: Major > > While creating a theme and looking for not correctly styled elements I came > across "some" not functional links and buttons in Compdoc. > This module seems not to be finished or working properly, because most of the > times, the buttons inside the appbar produce errors or just empty pages. > Even when searching for existing elements and then clicking on them to > examine or edit them will mostly create an error (example: go to compdoc, > search for template child, click edit on some random found element -> error). > Sometimes the menu which is included inside the appbar, mostly the menu > called "tree", need the contentId for the buttons to work. > Including this menu while creating a new entry will result in every button > not working and throwing an error, except the edit button, which will produce > a completely empty page. > Those things appear all over the module, trying some button or clicking some > link resulted in an error screen more than it resulted in something actually > working. > This should either be fixed or removed, if this doesn't has a real purpose at > all. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-10786) Wrong translation in PartyUiLabels
Dennis Balkir created OFBIZ-10786: - Summary: Wrong translation in PartyUiLabels Key: OFBIZ-10786 URL: https://issues.apache.org/jira/browse/OFBIZ-10786 Project: OFBiz Issue Type: Improvement Components: party Affects Versions: Trunk Reporter: Dennis Balkir Attachments: PartyUiLabels.patch There was a wrong german translation in PartyUiLabels. Just did a quick fix -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735614#comment-16735614 ] Dennis Balkir commented on OFBIZ-4361: -- Hi [~gil portenseigne], I just have a small question. In my implementation, I designed it in a way, that the user who clicks on the link for the password reset has to provide the his/her username in the process. I did that, so that it maybe would not be that easy to use another persons link to reset his/her password, should someone grab the mail. With the token I wrote, it will then check, if the token ID provided in the link and the username entered by the user are connected correctly and if not, the user can not set a new password. I may be a little paranoid, but I think this adds another level of security to this process. Is it possible to add a feature similar to this to the process? I don't really know what kind of limitations there are with the JWT, but I guess that should be possible somehow. Thanks PS: [~jacques.le.roux], I think your points are quite well exlplained. This seems like a valid solution, if I didn't miss anything, thanks for exlaining > Any ecommerce user has the ability to reset anothers password (including > admin) via "Forget Your Password" > -- > > Key: OFBIZ-4361 > URL: https://issues.apache.org/jira/browse/OFBIZ-4361 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 11.04, Release Branch 13.07, Release > Branch 14.12, Trunk, Release Branch 15.12, Release Branch 16.11, Release > Branch 17.12 > Environment: Ubuntu and others >Reporter: mz4wheeler >Assignee: Jacques Le Roux >Priority: Major > Labels: security > Attachments: OFBIZ-4361.patch, OFBIZ-4361_OneScreen.patch, > OFBIZ-4361_ReworkPasswordLogic.patch, OFBIZ-4361_ReworkPasswordLogic.patch, > OFBIZ-4361_Token-Password-Registration.patch > > > Currently, any user (via ecommerce "Forget Your Password") has the ability to > reset another users password, including "admin" without permission. By > simply entering "admin" and clicking "Email Password", the following is > displayed. > The following occurred: > A new password has been created and sent to you. Please check your Email. > This now forces the user of the ERP to change their password. It is also > possible to generate a dictionary attack against ofbiz because there is no > capta code required. This is serious security risk. > This feature could be reduced to a certain sub-set of users, whose login name > is optionally in the format of an email address, and maybe require a capta > code to prevent dictionary attacks. > For example, limit the feature to role "Customer" of type "Person" which was > generated via an ecommerce transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[
https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732074#comment-16732074
]
Dennis Balkir commented on OFBIZ-4361:
--
Hi [~jacques.le.roux], [~soledad],
first some things on Jacques comment.
{quote}
Here lies a little issue with the jti (Json Token Id). As the feature is
stateless, we can't rely on a session to store an unique value to check (as in
most cases with JWT use).
An alternative is to store this temporary value in the DB, but we want to
avoid storing things in DB for JWT.
Another better alternative is to use the JWT secret key. It would not be
unique by JWT as the specifications require. But we always know it, and an
attacker should not, else anyway the JWT is useless. This get us back to how
store the secret key. We agreed about keeping it as a property OOTB; and giving
a link from the security properties file to suggest how to better do it in
production. It's not blocking us, but is something we still have to do, I
created OFBIZ-10751 for that.
{quote}
I don't really know if it woud be much safer to store a secret key, which won't
be unique for one JWT but instead is used for many, inside of a text document.
In case of security this seems kind of counter intuitive to me. And I don't
even think it would be better than having multiple token stored inside of the
database.
The JWT would maybe be a great solution, but in our case, where we could not
save something in the session, since it should work independent of browser
sessions, the JWT might just not be the thing we are looking for, especially if
it includes saving one secret key in a document.
Furthermore, and maybe only in my opinion, the token provided by me is much
more versatile as it is fully customisable and can be stored over long periods
of time, if needed to.
For the fact that it is internally associated with the userLogin, that it will
be used for, it is using OFBiz internal logic and is very easy to verify for
the user, even with so little information given, as the Token-ID in an URL.
No additional information is given to someone who might be grabbing the mail or
whatever.
Maybe there are some advantages, that I missed, but I think that the JWT might
just not be the right solution in terms of overall security and usefullness for
this application. It seems like it would be good for inner-session
verification, but this is not always given for our problem and therefore this
problem might need another solution.
Now for Nicolas:
I did not yet had time to take a real review on your proposal, maybe I should
do this asap.
At first, the idea to combine the two solutions to make a better and maybe more
versatile and secure one, seems not like a bad idea to me.
> Any ecommerce user has the ability to reset anothers password (including
> admin) via "Forget Your Password"
> --
>
> Key: OFBIZ-4361
> URL: https://issues.apache.org/jira/browse/OFBIZ-4361
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Release Branch 11.04, Release Branch 13.07, Release
> Branch 14.12, Trunk, Release Branch 15.12, Release Branch 16.11, Release
> Branch 17.12
> Environment: Ubuntu and others
>Reporter: mz4wheeler
>Assignee: Jacques Le Roux
>Priority: Major
> Labels: security
> Attachments: OFBIZ-4361.patch, OFBIZ-4361_OneScreen.patch,
> OFBIZ-4361_ReworkPasswordLogic.patch, OFBIZ-4361_ReworkPasswordLogic.patch,
> OFBIZ-4361_Token-Password-Registration.patch
>
>
> Currently, any user (via ecommerce "Forget Your Password") has the ability to
> reset another users password, including "admin" without permission. By
> simply entering "admin" and clicking "Email Password", the following is
> displayed.
> The following occurred:
> A new password has been created and sent to you. Please check your Email.
> This now forces the user of the ERP to change their password. It is also
> possible to generate a dictionary attack against ofbiz because there is no
> capta code required. This is serious security risk.
> This feature could be reduced to a certain sub-set of users, whose login name
> is optionally in the format of an email address, and maybe require a capta
> code to prevent dictionary attacks.
> For example, limit the feature to role "Customer" of type "Person" which was
> generated via an ecommerce transaction.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724890#comment-16724890 ] Dennis Balkir commented on OFBIZ-4361: -- Hi [~jacques.le.roux], since we need to somehow preserve the token, as the user maybe won't use it in the same moment/session, the JWT has to be saved somewhere. To connect it back to the UserLogin as it is in my solution, there would be the neccessarity to store it in the DB, which won't make it an any better solution, than the new style of token IMO. Feel free to correct me, as I may have misunderstood something here, thanks. > Any ecommerce user has the ability to reset anothers password (including > admin) via "Forget Your Password" > -- > > Key: OFBIZ-4361 > URL: https://issues.apache.org/jira/browse/OFBIZ-4361 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 11.04, Release Branch 13.07, Release > Branch 14.12, Trunk, Release Branch 15.12, Release Branch 16.11, Release > Branch 17.12 > Environment: Ubuntu and others >Reporter: mz4wheeler >Assignee: Michael Brohl >Priority: Major > Labels: security > Attachments: OFBIZ-4361.patch, OFBIZ-4361_OneScreen.patch, > OFBIZ-4361_ReworkPasswordLogic.patch, OFBIZ-4361_ReworkPasswordLogic.patch, > OFBIZ-4361_Token-Password-Registration.patch > > > Currently, any user (via ecommerce "Forget Your Password") has the ability to > reset another users password, including "admin" without permission. By > simply entering "admin" and clicking "Email Password", the following is > displayed. > The following occurred: > A new password has been created and sent to you. Please check your Email. > This now forces the user of the ERP to change their password. It is also > possible to generate a dictionary attack against ofbiz because there is no > capta code required. This is serious security risk. > This feature could be reduced to a certain sub-set of users, whose login name > is optionally in the format of an email address, and maybe require a capta > code to prevent dictionary attacks. > For example, limit the feature to role "Customer" of type "Person" which was > generated via an ecommerce transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir reassigned OFBIZ-4361: Assignee: Dennis Balkir (was: Michael Brohl) > Any ecommerce user has the ability to reset anothers password (including > admin) via "Forget Your Password" > -- > > Key: OFBIZ-4361 > URL: https://issues.apache.org/jira/browse/OFBIZ-4361 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 11.04, Release Branch 13.07, Release > Branch 14.12, Trunk, Release Branch 15.12, Release Branch 16.11, Release > Branch 17.12 > Environment: Ubuntu and others >Reporter: mz4wheeler >Assignee: Dennis Balkir >Priority: Major > Labels: security > Attachments: OFBIZ-4361.patch, OFBIZ-4361_OneScreen.patch, > OFBIZ-4361_ReworkPasswordLogic.patch, OFBIZ-4361_ReworkPasswordLogic.patch, > OFBIZ-4361_Token-Password-Registration.patch > > > Currently, any user (via ecommerce "Forget Your Password") has the ability to > reset another users password, including "admin" without permission. By > simply entering "admin" and clicking "Email Password", the following is > displayed. > The following occurred: > A new password has been created and sent to you. Please check your Email. > This now forces the user of the ERP to change their password. It is also > possible to generate a dictionary attack against ofbiz because there is no > capta code required. This is serious security risk. > This feature could be reduced to a certain sub-set of users, whose login name > is optionally in the format of an email address, and maybe require a capta > code to prevent dictionary attacks. > For example, limit the feature to role "Customer" of type "Person" which was > generated via an ecommerce transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10231) Convert ProductServices.xml mini lang to groovy
[ https://issues.apache.org/jira/browse/OFBIZ-10231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16714456#comment-16714456 ] Dennis Balkir commented on OFBIZ-10231: --- Hi [~mbrohl], [~pfm.smits], I am currently not working on it, since I have some work to do in some projects. But as soon as I can spare some time, I will start with this issue. Thanks in advance for your patience > Convert ProductServices.xml mini lang to groovy > --- > > Key: OFBIZ-10231 > URL: https://issues.apache.org/jira/browse/OFBIZ-10231 > Project: OFBiz > Issue Type: Sub-task > Components: product >Affects Versions: Trunk >Reporter: Dennis Balkir >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-4361: - Attachment: OFBIZ-4361_Token-Password-Registration.patch > Any ecommerce user has the ability to reset anothers password (including > admin) via "Forget Your Password" > -- > > Key: OFBIZ-4361 > URL: https://issues.apache.org/jira/browse/OFBIZ-4361 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 11.04, Release Branch 13.07, Release > Branch 14.12, Trunk, Release Branch 15.12, Release Branch 16.11, Release > Branch 17.12 > Environment: Ubuntu and others >Reporter: mz4wheeler >Assignee: Michael Brohl >Priority: Major > Labels: security > Attachments: OFBIZ-4361.patch, OFBIZ-4361_OneScreen.patch, > OFBIZ-4361_ReworkPasswordLogic.patch, OFBIZ-4361_ReworkPasswordLogic.patch, > OFBIZ-4361_Token-Password-Registration.patch > > > Currently, any user (via ecommerce "Forget Your Password") has the ability to > reset another users password, including "admin" without permission. By > simply entering "admin" and clicking "Email Password", the following is > displayed. > The following occurred: > A new password has been created and sent to you. Please check your Email. > This now forces the user of the ERP to change their password. It is also > possible to generate a dictionary attack against ofbiz because there is no > capta code required. This is serious security risk. > This feature could be reduced to a certain sub-set of users, whose login name > is optionally in the format of an email address, and maybe require a capta > code to prevent dictionary attacks. > For example, limit the feature to role "Customer" of type "Person" which was > generated via an ecommerce transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-4361: - Attachment: (was: OFBIZ-4361_Token-Password-Registration.patch) > Any ecommerce user has the ability to reset anothers password (including > admin) via "Forget Your Password" > -- > > Key: OFBIZ-4361 > URL: https://issues.apache.org/jira/browse/OFBIZ-4361 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 11.04, Release Branch 13.07, Release > Branch 14.12, Trunk, Release Branch 15.12, Release Branch 16.11, Release > Branch 17.12 > Environment: Ubuntu and others >Reporter: mz4wheeler >Assignee: Michael Brohl >Priority: Major > Labels: security > Attachments: OFBIZ-4361.patch, OFBIZ-4361_OneScreen.patch, > OFBIZ-4361_ReworkPasswordLogic.patch, OFBIZ-4361_ReworkPasswordLogic.patch, > OFBIZ-4361_Token-Password-Registration.patch > > > Currently, any user (via ecommerce "Forget Your Password") has the ability to > reset another users password, including "admin" without permission. By > simply entering "admin" and clicking "Email Password", the following is > displayed. > The following occurred: > A new password has been created and sent to you. Please check your Email. > This now forces the user of the ERP to change their password. It is also > possible to generate a dictionary attack against ofbiz because there is no > capta code required. This is serious security risk. > This feature could be reduced to a certain sub-set of users, whose login name > is optionally in the format of an email address, and maybe require a capta > code to prevent dictionary attacks. > For example, limit the feature to role "Customer" of type "Person" which was > generated via an ecommerce transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10653) Missing nullcheck in service createContactListParty
[
https://issues.apache.org/jira/browse/OFBIZ-10653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691911#comment-16691911
]
Dennis Balkir commented on OFBIZ-10653:
---
This patch adds a nullcheck for the partyEmail and provides a better
errorMessage for the in-request service call.
In addition the failing partyID will be logged for the admin to see
> Missing nullcheck in service createContactListParty
> ---
>
> Key: OFBIZ-10653
> URL: https://issues.apache.org/jira/browse/OFBIZ-10653
> Project: OFBiz
> Issue Type: Bug
> Components: marketing
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Major
> Attachments: OFBIZ-10653_ContactListServices.patch
>
>
> This service searches for the primary email-address of the given party, if it
> doesn't have a preffered contact mechanism ID in its parameters.
> For this it uses the service {{getPartyEmail}} which, as a result, can
> deliver an optional email-address.
> This is where the problem is: the result is optional.
> Without any further checks, the result, empty or not, will be used to call
> another service called {{createContactListPartyStatus}}. For this service the
> field {{preferredContactMechId}} is a non optional input value, which is set
> before from the result of {{getPartyEmail}}.
> If the party email could not be found, because a party group is added, or
> simply because the party has no mail given for some reason, this service call
> will result in an error because of missing parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10653) Missing nullcheck in service createContactListParty
[
https://issues.apache.org/jira/browse/OFBIZ-10653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-10653:
--
Attachment: OFBIZ-10653_ContactListServices.patch
> Missing nullcheck in service createContactListParty
> ---
>
> Key: OFBIZ-10653
> URL: https://issues.apache.org/jira/browse/OFBIZ-10653
> Project: OFBiz
> Issue Type: Bug
> Components: marketing
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Major
> Attachments: OFBIZ-10653_ContactListServices.patch
>
>
> This service searches for the primary email-address of the given party, if it
> doesn't have a preffered contact mechanism ID in its parameters.
> For this it uses the service {{getPartyEmail}} which, as a result, can
> deliver an optional email-address.
> This is where the problem is: the result is optional.
> Without any further checks, the result, empty or not, will be used to call
> another service called {{createContactListPartyStatus}}. For this service the
> field {{preferredContactMechId}} is a non optional input value, which is set
> before from the result of {{getPartyEmail}}.
> If the party email could not be found, because a party group is added, or
> simply because the party has no mail given for some reason, this service call
> will result in an error because of missing parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OFBIZ-10653) Missing nullcheck in service createContactListParty
Dennis Balkir created OFBIZ-10653:
-
Summary: Missing nullcheck in service createContactListParty
Key: OFBIZ-10653
URL: https://issues.apache.org/jira/browse/OFBIZ-10653
Project: OFBiz
Issue Type: Bug
Components: marketing
Affects Versions: Trunk
Reporter: Dennis Balkir
This service searches for the primary email-address of the given party, if it
doesn't have a preffered contact mechanism ID in its parameters.
For this it uses the service {{getPartyEmail}} which, as a result, can deliver
an optional email-address.
This is where the problem is: the result is optional.
Without any further checks, the result, empty or not, will be used to call
another service called {{createContactListPartyStatus}}. For this service the
field {{preferredContactMechId}} is a non optional input value, which is set
before from the result of {{getPartyEmail}}.
If the party email could not be found, because a party group is added, or
simply because the party has no mail given for some reason, this service call
will result in an error because of missing parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10601) Add a framework method to get main webapp menu with the webapp name
[
https://issues.apache.org/jira/browse/OFBIZ-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661940#comment-16661940
]
Dennis Balkir commented on OFBIZ-10601:
---
Hi Julien,
we have implemented it this way:
# We have made a new xml-file calles {{menus.xml}} in which we include all
menus, that we want to load.
It looks like this:
{code:xml}
http://www.w3.org/2001/XMLSchema-instance;
xmlns="http://ofbiz.apache.org/Widget-Menu;
xsi:schemaLocation="Component://bootstrap-basic/menu-include.xsd">
{code}
# We wrote a new class, which then reads the xml file and puts all menus in a
map:
{code:java}
/**
* Creates a Map of all Application Menus
*
* @param resourceName
*Componentlocation of the menus.xml
* @return modelMenusMap which contains all Menus
* @throws IOException
* @throws SAXException
* @throws ParserConfigurationException
*/
public static Map getMenusMapFromLocation(String
resourceName) throws IOException, SAXException,
ParserConfigurationException {
Map modelMenusMap = new HashMap<>();
URL menuFileUrl = FlexibleLocation.resolveLocation(resourceName);
Document menusFileDoc = UtilXml.readXmlDocument(menuFileUrl, true,
true);
modelMenusMap = readAppMenusDocument(menusFileDoc);
menuLocationCache.putIfAbsent(resourceName, modelMenusMap);
modelMenusMap = menuLocationCache.get(resourceName);
if (UtilValidate.isEmpty(modelMenusMap)) {
throw new IllegalArgumentException("Could not find menu file in
location [" + resourceName + "]");
}
if (modelMenusMap.values() == null) {
throw new IllegalArgumentException("no Values in modelMenusMap");
}
return modelMenusMap;
}
/**
* Reads Xml File and creates Map of Menus, based on given Doc
*
* @param menusFileDoc
*menus File, where Location,Name and Application are defined
* @return modelMenusMap which contains Menus
* @throws IOException
* @throws SAXException
* @throws ParserConfigurationException
*/
public static Map readAppMenusDocument(Document
menusFileDoc) throws IOException, SAXException,
ParserConfigurationException {
Map modelMenusMap = new HashMap<>();
if (menusFileDoc != null) {
// read document and construct ModelMenu for each menu element
Element rootElement = menusFileDoc.getDocumentElement();
if (!"menus".equalsIgnoreCase(rootElement.getTagName())) {
rootElement = UtilXml.firstChildElement(rootElement, "menus");
}
for (Element menuElement : UtilXml.childElementList(rootElement,
"include-menu")) {
String name = menuElement.getAttribute("name");
String location = menuElement.getAttribute("location");
String application = menuElement.getAttribute("title");
if (!location.equals("")) {
modelMenusMap.put(application,
getMenuFromLocation(location, name));
} else {
modelMenusMap.put(application, null);
}
}
}
return modelMenusMap;
}
{code}
# In the template {{TopAppBar.ftl}} we assigned a variable of the type map,
which uses this helper method to get all the menus:
{code:java}
<#assign MenuAppbar =
Static[classPath].getMenusMapFromLocation("component://theme/menus.xml")>
{code}
# We iterate through the child menu of the application like this:
{code:java}
<#assign activeApp = thisApp?remove_beginning("/")>
<#if uiLabelMap?exists>
${uiLabelMap[display.title]}<#else> ${display.title}.
<#-- Sub Menus -->
<#assign activeAppBar = MenuAppbar[activeApp]!>
<#if activeAppBar?has_content>
<#assign appbar = activeAppBar.getMenuItemList()>
<#list appbar as app>
<#assign ui = app.title>
<#if currApp == activeApp>
<#assign urlTarget = thisApp +"/control/"
+app.link.getTargetExdr()>
<#else>
<#assign urlTarget = thisApp +"/control/"
+app.link.getTargetExdr() + externalKeyParam!>
><@ui?interpret/>
<#else>
<#assign urlTarget = thisApp +"/control/main">
${uiLabelMap.CommonMain}
{code}
For Facility it will produce something like this as a child menu of the
application:
{code}
Main
Facilities
Facility Groups
Inventory Item
Labels
Shipment Gateway
Config
Shipments
Reports
{code}
I hope I didn't miss anything.
If you have more questions or something doesn't make sense, please feel free to
ask.
Thanks
> Add a framework method to get main webapp menu with the
[jira] [Commented] (OFBIZ-10599) Create an "url-redirect" response type
[ https://issues.apache.org/jira/browse/OFBIZ-10599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660761#comment-16660761 ] Dennis Balkir commented on OFBIZ-10599: --- There is a new patch, with a correct message > Create an "url-redirect" response type > -- > > Key: OFBIZ-10599 > URL: https://issues.apache.org/jira/browse/OFBIZ-10599 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Dennis Balkir >Priority: Minor > Attachments: OFBIZ-10599_RequestHandler_url-redirect.patch > > > As discussed with Dennis in OFBIZ-10569, the idea is to implement an > "url-redirect" response type where an external URL can be set with redirected > parameters like it's done with request-redirect which is only internal. > Thinking about it we could maybe enhance request-redirect to do both with a > specific syntax for external URLs, but it's only thoughts, did not check > code... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10599) Create an "url-redirect" response type
[ https://issues.apache.org/jira/browse/OFBIZ-10599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-10599: -- Attachment: OFBIZ-10599_RequestHandler_url-redirect.patch > Create an "url-redirect" response type > -- > > Key: OFBIZ-10599 > URL: https://issues.apache.org/jira/browse/OFBIZ-10599 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Dennis Balkir >Priority: Minor > Attachments: OFBIZ-10599_RequestHandler_url-redirect.patch > > > As discussed with Dennis in OFBIZ-10569, the idea is to implement an > "url-redirect" response type where an external URL can be set with redirected > parameters like it's done with request-redirect which is only internal. > Thinking about it we could maybe enhance request-redirect to do both with a > specific syntax for external URLs, but it's only thoughts, did not check > code... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10599) Create an "url-redirect" response type
[ https://issues.apache.org/jira/browse/OFBIZ-10599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-10599: -- Attachment: (was: OFBIZ-10599_RequestHandler_url-redirect.patch) > Create an "url-redirect" response type > -- > > Key: OFBIZ-10599 > URL: https://issues.apache.org/jira/browse/OFBIZ-10599 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Dennis Balkir >Priority: Minor > Attachments: OFBIZ-10599_RequestHandler_url-redirect.patch > > > As discussed with Dennis in OFBIZ-10569, the idea is to implement an > "url-redirect" response type where an external URL can be set with redirected > parameters like it's done with request-redirect which is only internal. > Thinking about it we could maybe enhance request-redirect to do both with a > specific syntax for external URLs, but it's only thoughts, did not check > code... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10599) Create an "url-redirect" response type
[ https://issues.apache.org/jira/browse/OFBIZ-10599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660737#comment-16660737 ] Dennis Balkir commented on OFBIZ-10599: --- Hi Jacques, you are right. I simply forgot to change the log message. I will upload a corrected patch in a few moments. > Create an "url-redirect" response type > -- > > Key: OFBIZ-10599 > URL: https://issues.apache.org/jira/browse/OFBIZ-10599 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Dennis Balkir >Priority: Minor > Attachments: OFBIZ-10599_RequestHandler_url-redirect.patch > > > As discussed with Dennis in OFBIZ-10569, the idea is to implement an > "url-redirect" response type where an external URL can be set with redirected > parameters like it's done with request-redirect which is only internal. > Thinking about it we could maybe enhance request-redirect to do both with a > specific syntax for external URLs, but it's only thoughts, did not check > code... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10599) Create an "url-redirect" response type
[
https://issues.apache.org/jira/browse/OFBIZ-10599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16660703#comment-16660703
]
Dennis Balkir commented on OFBIZ-10599:
---
This patch is an updated version of my patch from the old issue and adds the
response-type "url-redirect".
This is simply used like request-redirect, except with URL.
Some exmaple code:
{code:java}
{code}
This will generate a URL like this: {{whatsapp://send?text=LoremIpsum}}, which
can be used to send a prepared WhatsApp message with given text to some other
person.
> Create an "url-redirect" response type
> --
>
> Key: OFBIZ-10599
> URL: https://issues.apache.org/jira/browse/OFBIZ-10599
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-10599_RequestHandler_url-redirect.patch
>
>
> As discussed with Dennis in OFBIZ-10569, the idea is to implement an
> "url-redirect" response type where an external URL can be set with redirected
> parameters like it's done with request-redirect which is only internal.
> Thinking about it we could maybe enhance request-redirect to do both with a
> specific syntax for external URLs, but it's only thoughts, did not check
> code...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OFBIZ-10599) Create an "url-redirect" response type
[ https://issues.apache.org/jira/browse/OFBIZ-10599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir reassigned OFBIZ-10599: - Assignee: Dennis Balkir > Create an "url-redirect" response type > -- > > Key: OFBIZ-10599 > URL: https://issues.apache.org/jira/browse/OFBIZ-10599 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Dennis Balkir >Priority: Minor > Attachments: OFBIZ-10599_RequestHandler_url-redirect.patch > > > As discussed with Dennis in OFBIZ-10569, the idea is to implement an > "url-redirect" response type where an external URL can be set with redirected > parameters like it's done with request-redirect which is only internal. > Thinking about it we could maybe enhance request-redirect to do both with a > specific syntax for external URLs, but it's only thoughts, did not check > code... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10599) Create an "url-redirect" response type
[ https://issues.apache.org/jira/browse/OFBIZ-10599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-10599: -- Attachment: OFBIZ-10599_RequestHandler_url-redirect.patch > Create an "url-redirect" response type > -- > > Key: OFBIZ-10599 > URL: https://issues.apache.org/jira/browse/OFBIZ-10599 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-10599_RequestHandler_url-redirect.patch > > > As discussed with Dennis in OFBIZ-10569, the idea is to implement an > "url-redirect" response type where an external URL can be set with redirected > parameters like it's done with request-redirect which is only internal. > Thinking about it we could maybe enhance request-redirect to do both with a > specific syntax for external URLs, but it's only thoughts, did not check > code... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10601) Add a framework method to get main webapp menu with the webapp name
[ https://issues.apache.org/jira/browse/OFBIZ-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16651251#comment-16651251 ] Dennis Balkir commented on OFBIZ-10601: --- Hi Julien, I will soon provide the things we have done, but please give me some time, so that I don't miss anything. Thanks > Add a framework method to get main webapp menu with the webapp name > --- > > Key: OFBIZ-10601 > URL: https://issues.apache.org/jira/browse/OFBIZ-10601 > Project: OFBiz > Issue Type: Improvement > Components: framework >Reporter: Julien NICOLAS >Assignee: Julien NICOLAS >Priority: Minor > Attachments: HomeMenu.png, webAppMainMenu.png > > > To improve theme management and provide better tools for new themes, I would > like to have a method that return the main menu of a webApp with the webApp > name. > The purpose is to have new theme with smarter UI like example in attached > screenshot. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10601) Add a framework method to get main webapp menu with the webapp name
[ https://issues.apache.org/jira/browse/OFBIZ-10601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649812#comment-16649812 ] Dennis Balkir commented on OFBIZ-10601: --- HI Julien, we recently made a theme with a function like this. If this helps, I could provide some examples and/or explanation of what we did to make that possible. > Add a framework method to get main webapp menu with the webapp name > --- > > Key: OFBIZ-10601 > URL: https://issues.apache.org/jira/browse/OFBIZ-10601 > Project: OFBiz > Issue Type: Improvement > Components: framework >Reporter: Julien NICOLAS >Assignee: Julien NICOLAS >Priority: Minor > Attachments: HomeMenu.png, webAppMainMenu.png > > > To improve theme management and provide better tools for new themes, I would > like to have a method that return the main menu of a webApp with the webApp > name. > The purpose is to have new theme with smarter UI like example in attached > screenshot. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10599) Create an "url-redirect" response type
[ https://issues.apache.org/jira/browse/OFBIZ-10599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-10599: -- Environment: As discussed with Dennis in OFBIZ-10569, the idea is to implement an "url-redirect" response type where an external URL can be set with redirected parameters like it's done with request-redirect which is only internal. Thinking about it we could maybe enhance request-redirect to do both with a specific syntax for external URLs, but it's only thoughts, did not check code... was: As discussed with Denis in OFBIZ-10569, the idea is to implement an "url-redirect" response type where an external URL can be set with redirected parameters like it's done with request-redirect which is only internal. Thinking about it we could maybe enhance request-redirect to do both with a specific syntax for external URLs, but it's only thoughts, did not check code... > Create an "url-redirect" response type > -- > > Key: OFBIZ-10599 > URL: https://issues.apache.org/jira/browse/OFBIZ-10599 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk > Environment: As discussed with Dennis in OFBIZ-10569, the idea is to > implement an "url-redirect" response type where an external URL can be set > with redirected parameters like it's done with request-redirect which is only > internal. > Thinking about it we could maybe enhance request-redirect to do both with a > specific syntax for external URLs, but it's only thoughts, did not check > code... >Reporter: Jacques Le Roux >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10569) Wrong handling of response type "cross-redirect"
[
https://issues.apache.org/jira/browse/OFBIZ-10569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16642956#comment-16642956
]
Dennis Balkir commented on OFBIZ-10569:
---
Hi Jacques,
yes please create another issue for this.
This will be a great feature to have and we can use the patch I made with
slight modifications as a starting point, since the modified code already
provides the feature.
We just have to change it up a bit, to make it a new type
> Wrong handling of response type "cross-redirect"
>
>
> Key: OFBIZ-10569
> URL: https://issues.apache.org/jira/browse/OFBIZ-10569
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Reporter: Dennis Balkir
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: 17.12.01, 16.11.06
>
> Attachments: OFBIZ-10569_RequestHandler.patch
>
>
> When using the response type "cross-redirect", OFBiz is not acting as
> expected.
> The description of the types "url" and "cross-redirect" is stated as follows
> in the file {{site-conf.xsd}}:
> {code:xml}
>
>
>
> Any URL, relative or absolute. Redirected parameters are not used, you
> can put them in the url.
>
>
>
>
>
>
> Works like URL but you can also pass redirected parameters.
>
>
>
> {code}
> The way, this is implemented in {{RequestHandler.java}} works slightly
> different:
> For the type "url", this is true, but for "cross-redirect", before putting
> the params in the link, it is checked, if the link begins with an "/".
> If not, it is added as the first char.
> This results in a link given like this: {{https://test.com}}
> will turn into this: {{/https://test.com}}, which will then be treated as an
> OFBiz internal link, like {{/catalog}}, and instead of be called externally,
> OFBiz tries to call it as an OFBiz-URL.
> This behavior is not correct and should therefore be corrected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10569) Wrong handling of response type "cross-redirect"
[
https://issues.apache.org/jira/browse/OFBIZ-10569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621717#comment-16621717
]
Dennis Balkir commented on OFBIZ-10569:
---
Hi Jacques,
{quote}You can with "url", but, as it's documented in site-conf.xsd, only using
params in the URL
{quote}
Yes, the documentation said that, but I don't actually get how this should work
with params, that need to be variable..
{quote}I'll be more for a new type ("url-redirect"?) and amend the
documentation. It's possible that users are using "cross-redirect" w/o
following the xsd docupentation
{quote}
This would be a good solution imo
Maybe this issue could be changed accordingly?
> Wrong handling of response type "cross-redirect"
>
>
> Key: OFBIZ-10569
> URL: https://issues.apache.org/jira/browse/OFBIZ-10569
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-10569_RequestHandler.patch
>
>
> When using the response type "cross-redirect", OFBiz is not acting as
> expected.
> The description of the types "url" and "cross-redirect" is stated as follows
> in the file {{site-conf.xsd}}:
> {code:xml}
>
>
>
> Any URL, relative or absolute. Redirected parameters are not used, you
> can put them in the url.
>
>
>
>
>
>
> Works like URL but you can also pass redirected parameters.
>
>
>
> {code}
> The way, this is implemented in {{RequestHandler.java}} works slightly
> different:
> For the type "url", this is true, but for "cross-redirect", before putting
> the params in the link, it is checked, if the link begins with an "/".
> If not, it is added as the first char.
> This results in a link given like this: {{https://test.com}}
> will turn into this: {{/https://test.com}}, which will then be treated as an
> OFBiz internal link, like {{/catalog}}, and instead of be called externally,
> OFBiz tries to call it as an OFBiz-URL.
> This behavior is not correct and should therefore be corrected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10569) Wrong handling of response type "cross-redirect"
[
https://issues.apache.org/jira/browse/OFBIZ-10569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621626#comment-16621626
]
Dennis Balkir commented on OFBIZ-10569:
---
Hi Jacques,
yes this makes sense to me.
But on the other hand, this means, that there simply is no possibility to
address an external url with params, which would be quite restrictive.
Since there are already different ways to open an internal url with params, why
not use this, or maybe make a new type, for external url with params?
This is documented this way, even if the documentation is wrong, but it gives
us the opportunity, to use it that way it could be used.
I see no problem in changing the code, if the documentation already states,
that it is used that way and since there are other types to open urls
internally.
> Wrong handling of response type "cross-redirect"
>
>
> Key: OFBIZ-10569
> URL: https://issues.apache.org/jira/browse/OFBIZ-10569
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-10569_RequestHandler.patch
>
>
> When using the response type "cross-redirect", OFBiz is not acting as
> expected.
> The description of the types "url" and "cross-redirect" is stated as follows
> in the file {{site-conf.xsd}}:
> {code:xml}
>
>
>
> Any URL, relative or absolute. Redirected parameters are not used, you
> can put them in the url.
>
>
>
>
>
>
> Works like URL but you can also pass redirected parameters.
>
>
>
> {code}
> The way, this is implemented in {{RequestHandler.java}} works slightly
> different:
> For the type "url", this is true, but for "cross-redirect", before putting
> the params in the link, it is checked, if the link begins with an "/".
> If not, it is added as the first char.
> This results in a link given like this: {{https://test.com}}
> will turn into this: {{/https://test.com}}, which will then be treated as an
> OFBiz internal link, like {{/catalog}}, and instead of be called externally,
> OFBiz tries to call it as an OFBiz-URL.
> This behavior is not correct and should therefore be corrected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10569) Wrong handling of response type "cross-redirect"
[
https://issues.apache.org/jira/browse/OFBIZ-10569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-10569:
--
Attachment: OFBIZ-10569_RequestHandler.patch
> Wrong handling of response type "cross-redirect"
>
>
> Key: OFBIZ-10569
> URL: https://issues.apache.org/jira/browse/OFBIZ-10569
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-10569_RequestHandler.patch
>
>
> When using the response type "cross-redirect", OFBiz is not acting as
> expected.
> The description of the types "url" and "cross-redirect" is stated as follows
> in the file {{site-conf.xsd}}:
> {code:xml}
>
>
>
> Any URL, relative or absolute. Redirected parameters are not used, you
> can put them in the url.
>
>
>
>
>
>
> Works like URL but you can also pass redirected parameters.
>
>
>
> {code}
> The way, this is implemented in {{RequestHandler.java}} works slightly
> different:
> For the type "url", this is true, but for "cross-redirect", before putting
> the params in the link, it is checked, if the link begins with an "/".
> If not, it is added as the first char.
> This results in a link given like this: {{https://test.com}}
> will turn into this: {{/https://test.com}}, which will then be treated as an
> OFBiz internal link, like {{/catalog}}, and instead of be called externally,
> OFBiz tries to call it as an OFBiz-URL.
> This behavior is not correct and should therefore be corrected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OFBIZ-10569) Wrong handling of response type "cross-redirect"
Dennis Balkir created OFBIZ-10569:
-
Summary: Wrong handling of response type "cross-redirect"
Key: OFBIZ-10569
URL: https://issues.apache.org/jira/browse/OFBIZ-10569
Project: OFBiz
Issue Type: Bug
Components: framework
Reporter: Dennis Balkir
When using the response type "cross-redirect", OFBiz is not acting as expected.
The description of the types "url" and "cross-redirect" is stated as follows in
the file {{site-conf.xsd}}:
{code:xml}
Any URL, relative or absolute. Redirected parameters are not used, you
can put them in the url.
Works like URL but you can also pass redirected parameters.
{code}
The way, this is implemented in {{RequestHandler.java}} works slightly
different:
For the type "url", this is true, but for "cross-redirect", before putting the
params in the link, it is checked, if the link begins with an "/".
If not, it is added as the first char.
This results in a link given like this: {{https://test.com}}
will turn into this: {{/https://test.com}}, which will then be treated as an
OFBiz internal link, like {{/catalog}}, and instead of be called externally,
OFBiz tries to call it as an OFBiz-URL.
This behavior is not correct and should therefore be corrected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613482#comment-16613482 ] Dennis Balkir edited comment on OFBIZ-4361 at 9/13/18 1:44 PM: --- Hi all. Some words on the patch I provided: *+Authentication-Token:+* There is a new entity called AUTHENTICATION_TOKEN. This is the core of this new logic. Its field are: * authenticationTokenId * ** This is the Primary Key of the entity ** It's a 36 symbol long randomly generated UUID * userLoginId ** A userLoginId is set, to make a connection between the token and the user * tokenUsageTypeId ** Can literally be anything. In the cases provided, this will be filled with "PASSWORD_RESET" and "ACCOUNT_VERIFICATION" * invalidationReason ** When the token becomes invalid, this will be empty. It's an easy way to see, or check, if the token was used or just simply went invalid, because of temporal reasons ** The service, which "uses" the token, will set "used for authentication" as the value of this field * thruDate * fromDate * lastUpdatedStamp * lastUpdatedTxStamp * createdStamp * createdTxStamp There are methods and services to find a single token by ID, by userLogin, by userLogin and type, to delete a single token or multiple token, for example a method which is called "deleteUsedTokensById", which will search for all used token with a specific type, for example "PASSWORD_RESET" and deletes them. There also is a worker class, which has more methods to, for example, find all expired token by type and returns them in a list. +*Other Methods and Services, which use the new entity:*+ There are some new classes and workers, which are aimed primarily into front-end user registration. When the user registers him-/herself, a service can be used, which is called "createDeactivatedUserWithVerification". This will create a disabled user, with "INITIALLY_DISABLED" set in the DISABLED_BY field and a randomly generated password. The service also creates a party, a person and contact data, if provided. After this a token is generated and an activation-link is sent to the customers mail. After clicking on the link, a prompt will ask for the users password. The user can now set his own password, which will activate the userLogin, and use the token. For this the token is valid for 24h. After this, the link is no longer valid, and the user has to register again. With this come methods for deleting all inactive, initially disabled user logins with expired token. This can easily be crafted into jobs and will then clean the database from dead user entries regularly. There also is a service for resending the verification mail, using the same token. The validation period that remains, is told to the user in the mail. Another use for the token is the forgot password function (*<<* *the original reason for this issue*). After clicking on the "email password" button, there now is something different happening. The user will get an email, with a link in it. This link will include a tokenID, by which the user will be identified. After clicking on the link, OFBiz checks, if this is still valid. If not, the user will be asked to generate a new mail. If active, a new form will show up, where the user has to enter his user name, a new password and the verification of that new password. After clicking submit, the given user login will be compared to the one which is set in the token under userLoginId. If not identical, the user will be told, that his/her user login did not match the one, that requested this password reset. If correct, and the passwords are matching too, the user password is changed with the service "updatePassword". For this the token is valid for 1h. If the link in the mail is not clicked, and the password gets changed manually by the user, the password will remain the same. It is not possible to reset random passwords of random users anymore, since the reset is happening at the moment, where the user provides the new password. A big thanks at this point to [~aarrach] for translating some new labels to french. Feel free to take you time to review and comment on this patch, since it is quite big. Thanks! was (Author: dennis balkir): Hi all. Some words on the patch I provided: *+Authentication-Token:+* There is a new entity called AUTHENTICATION_TOKEN. This is the core of this new logic. Its field are: * authenticationTokenId ** This is the Primary Key of the entity ** It's a 36 symbol long randomly generated UUID * userLoginId ** A userLoginId is set, to make a connection between the token and the user * tokenUsageTypeId ** Can literally be anything. In the cases provided, this will be filled with "PASSWORD_RESET" and "ACCOUNT_VERIFICATION" * invalidationReason ** When the token becomes invalid, this will be empty. It's an easy
[jira] [Updated] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-4361: - Attachment: OFBIZ-4361_Token-Password-Registration.patch > Any ecommerce user has the ability to reset anothers password (including > admin) via "Forget Your Password" > -- > > Key: OFBIZ-4361 > URL: https://issues.apache.org/jira/browse/OFBIZ-4361 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 11.04, Release Branch 13.07, Release > Branch 14.12, Trunk, Release Branch 15.12, Release Branch 16.11, Release > Branch 17.12 > Environment: Ubuntu and others >Reporter: mz4wheeler >Assignee: Michael Brohl >Priority: Major > Labels: security > Attachments: OFBIZ-4361.patch, OFBIZ-4361_OneScreen.patch, > OFBIZ-4361_ReworkPasswordLogic.patch, OFBIZ-4361_ReworkPasswordLogic.patch, > OFBIZ-4361_Token-Password-Registration.patch > > > Currently, any user (via ecommerce "Forget Your Password") has the ability to > reset another users password, including "admin" without permission. By > simply entering "admin" and clicking "Email Password", the following is > displayed. > The following occurred: > A new password has been created and sent to you. Please check your Email. > This now forces the user of the ERP to change their password. It is also > possible to generate a dictionary attack against ofbiz because there is no > capta code required. This is serious security risk. > This feature could be reduced to a certain sub-set of users, whose login name > is optionally in the format of an email address, and maybe require a capta > code to prevent dictionary attacks. > For example, limit the feature to role "Customer" of type "Person" which was > generated via an ecommerce transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613482#comment-16613482 ] Dennis Balkir commented on OFBIZ-4361: -- Hi all. Some words on the patch I provided: *+Authentication-Token:+* There is a new entity called AUTHENTICATION_TOKEN. This is the core of this new logic. Its field are: * authenticationTokenId ** This is the Primary Key of the entity ** It's a 36 symbol long randomly generated UUID * userLoginId ** A userLoginId is set, to make a connection between the token and the user * tokenUsageTypeId ** Can literally be anything. In the cases provided, this will be filled with "PASSWORD_RESET" and "ACCOUNT_VERIFICATION" * invalidationReason ** When the token becomes invalid, this will be empty. It's an easy way to see, or check, if the token was used or just simply went invalid, because of temporal reasons ** The service, which "uses" the token, will set "used for authentication" as the value of this field * thruDate * fromDate * lastUpdatedStamp * lastUpdatedTxStamp * createdStamp * createdTxStamp There are methods and services to find a single token by ID, by userLogin, by userLogin and type, to delete a single token or multiple token, for example a method which is called "deleteUsedTokensById", which will search for all used token with a specific type, for example "PASSWORD_RESET" and deletes them. There also is a worker class, which has more methods to, for example, find all expired token by type and returns them in a list. +*Other Methods and Services, which use the new entity:*+ There are some new classes and workers, which are aimed primarily into front-end user registration. When the user registers him-/herself, a service can be used, which is called "createDeactivatedUserWithVerification". This will create a disabled user, with "INITIALLY_DISABLED" set in the DISABLED_BY field and a randomly generated password. The service also creates a party, a person and contact data, if provided. After this a token is generated and an activation-link is sent to the customers mail. After clicking on the link, a prompt will ask for the users password. The user can now set his own password, which will activate the userLogin, and use the token. For this the token is valid for 24h. After this, the link is no longer valid, and the user has to register again. With this come methods for deleting all inactive, initially disabled user logins with expired token. This can easily be crafted into jobs and will then clean the database from dead user entries regularly. There also is a service for resending the verification mail, using the same token. The validation period that remains, is told to the user in the mail. Another use for the token is the forgot password function (*<<* *the original reason for this issue*). After clicking on the "email password" button, there now is something different happening. The user will get an email, with a link in it. This link will include a tokenID, by which the user will be identified. After clicking on the link, OFBiz checks, if this is still valid. If not, the user will be asked to generate a new mail. If active, a new form will show up, where the user has to enter his user name, a new password and the verification of that new password. After clicking submit, the given user login will be compared to the one which is set in the token under userLoginId. If not identical, the user will be told, that his/her user login did not match the one, that requested this password reset. If correct, and the passwords are matching too, the user password is changed with the service "updatePassword". For this the token is valid for 1h. If the link in the mail is not clicked, and the password gets changed manually by the user, the password will remain the same. It is not possible to reset random passwords of random users anymore, since the reset is happening at the moment, where the user provides the new password. A big thanks at this point to [~aarrach] for translating all new labels to french. Feel free to take you time to review and comment on this patch, since it is quite big. Thanks! > Any ecommerce user has the ability to reset anothers password (including > admin) via "Forget Your Password" > -- > > Key: OFBIZ-4361 > URL: https://issues.apache.org/jira/browse/OFBIZ-4361 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 11.04, Release Branch 13.07, Release > Branch 14.12, Trunk, Release Branch 15.12, Release Branch 16.11, Release > Branch 17.12 > Environment: Ubuntu and others >Reporter: mz4wheeler >Assignee: Michael Brohl >
[jira] [Commented] (OFBIZ-4361) Any ecommerce user has the ability to reset anothers password (including admin) via "Forget Your Password"
[ https://issues.apache.org/jira/browse/OFBIZ-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16609071#comment-16609071 ] Dennis Balkir commented on OFBIZ-4361: -- Hi [~pfm.smits], I am currently working on the solution Michael mentioned. This is nearly finished, but I am occupied with other projects, this is the reason, why it takes so long. The solution we are using, will not only use a generated token to create a link, but the token can also be used for user registration and various other things. We already use the token for user registration in projects we are working on, so there already are methods implemented for this case and the token in general. There should be time to finish this up in a few days. I hope, this won't cause any inconvenience > Any ecommerce user has the ability to reset anothers password (including > admin) via "Forget Your Password" > -- > > Key: OFBIZ-4361 > URL: https://issues.apache.org/jira/browse/OFBIZ-4361 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Release Branch 11.04, Release Branch 13.07, Release > Branch 14.12, Trunk, Release Branch 15.12, Release Branch 16.11, Release > Branch 17.12 > Environment: Ubuntu and others >Reporter: mz4wheeler >Assignee: Michael Brohl >Priority: Major > Labels: security > Attachments: OFBIZ-4361.patch, OFBIZ-4361_OneScreen.patch, > OFBIZ-4361_ReworkPasswordLogic.patch, OFBIZ-4361_ReworkPasswordLogic.patch > > > Currently, any user (via ecommerce "Forget Your Password") has the ability to > reset another users password, including "admin" without permission. By > simply entering "admin" and clicking "Email Password", the following is > displayed. > The following occurred: > A new password has been created and sent to you. Please check your Email. > This now forces the user of the ERP to change their password. It is also > possible to generate a dictionary attack against ofbiz because there is no > capta code required. This is serious security risk. > This feature could be reduced to a certain sub-set of users, whose login name > is optionally in the format of an email address, and maybe require a capta > code to prevent dictionary attacks. > For example, limit the feature to role "Customer" of type "Person" which was > generated via an ecommerce transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10541) Add a gradle task to compile less files in css and minify
[ https://issues.apache.org/jira/browse/OFBIZ-10541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594833#comment-16594833 ] Dennis Balkir edited comment on OFBIZ-10541 at 8/28/18 11:07 AM: - Hi [~julien.nicolas], the file "minify_gradle.patch" contains the gradle task which Michael Brohl mentioned. We use this in the plug-in folder, but it can easily be extended to work with whole OFBiz. We had a discussion here, on how it should be used. That's the reason why this needs a list in form of a .txt file. In this file you have to specify the paths of the files you want to minify. This makes it possible to accurately define which files should be minified and which should be left out. Unfortunately there is no mechanism to compile less or sass files in it, but this will compress css and js files to min.css and min.js. Hope this helps was (Author: dennis balkir): Hi [~julien.nicolas], this is the gradle task which Michael Brohl mentioned. We use this in the plug-in folder, but it can easily be extended to work with whole OFBiz. We had a discussion here, on how it should be used. That's the reason why this needs a list in form of a .txt file. In this file you have to specify the paths of the files you want to minify. This makes it possible to accurately define which files should be minified and which should be left out. Unfortunately there is no mechanism to compile less or sass files in it, but this will compress css and js files to min.css and min.js. Hope this helps > Add a gradle task to compile less files in css and minify > - > > Key: OFBIZ-10541 > URL: https://issues.apache.org/jira/browse/OFBIZ-10541 > Project: OFBiz > Issue Type: Improvement > Components: themes >Affects Versions: Trunk, Upcoming Branch >Reporter: Julien NICOLAS >Assignee: Julien NICOLAS >Priority: Trivial > Attachments: minify_gradlew.patch > > > For theme optimization, I would like to compile less files to css file. > In this way, we can remove the js compilation script from theme. > In the same times, I propose to minify and compress css files. > For debugging, css files will not be compress nor minified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10541) Add a gradle task to compile less files in css and minify
[ https://issues.apache.org/jira/browse/OFBIZ-10541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594833#comment-16594833 ] Dennis Balkir commented on OFBIZ-10541: --- Hi [~julien.nicolas], this is the gradle task which Michael Brohl mentioned. We use this in the plug-in folder, but it can easily be extended to work with whole OFBiz. We had a discussion here, on how it should be used. That's the reason why this needs a list in form of a .txt file. In this file you have to specify the paths of the files you want to minify. This makes it possible to accurately define which files should be minified and which should be left out. Unfortunately there is no mechanism to compile less or sass files in it, but this will compress css and js files to min.css and min.js. Hope this helps > Add a gradle task to compile less files in css and minify > - > > Key: OFBIZ-10541 > URL: https://issues.apache.org/jira/browse/OFBIZ-10541 > Project: OFBiz > Issue Type: Improvement > Components: themes >Affects Versions: Trunk, Upcoming Branch >Reporter: Julien NICOLAS >Assignee: Julien NICOLAS >Priority: Trivial > Attachments: minify_gradlew.patch > > > For theme optimization, I would like to compile less files to css file. > In this way, we can remove the js compilation script from theme. > In the same times, I propose to minify and compress css files. > For debugging, css files will not be compress nor minified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10541) Add a gradle task to compile less files in css and minify
[ https://issues.apache.org/jira/browse/OFBIZ-10541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Balkir updated OFBIZ-10541: -- Attachment: minify_gradlew.patch > Add a gradle task to compile less files in css and minify > - > > Key: OFBIZ-10541 > URL: https://issues.apache.org/jira/browse/OFBIZ-10541 > Project: OFBiz > Issue Type: Improvement > Components: themes >Affects Versions: Trunk, Upcoming Branch >Reporter: Julien NICOLAS >Assignee: Julien NICOLAS >Priority: Trivial > Attachments: minify_gradlew.patch > > > For theme optimization, I would like to compile less files to css file. > In this way, we can remove the js compilation script from theme. > In the same times, I propose to minify and compress css files. > For debugging, css files will not be compress nor minified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10506) Initial set of hasLoogedOut flag when logging in
[
https://issues.apache.org/jira/browse/OFBIZ-10506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571259#comment-16571259
]
Dennis Balkir commented on OFBIZ-10506:
---
Since every users flag is initially null, this login check never works.
With the patch provided, when the user logs in, the flag is set to N if it is
null and this fixes the bug
> Initial set of hasLoogedOut flag when logging in
>
>
> Key: OFBIZ-10506
> URL: https://issues.apache.org/jira/browse/OFBIZ-10506
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-10506.patch
>
>
> When setting up a new OFBiz with loadAll all the user logins are initially
> created with the flag {{hasLoggedOut}} set to null.
> This causes problems, when the method {{isUserLoggedIn}} from {{LoginWorker}}
> is used, since this checks if the flag is not null or N, and if it is null or
> not N it will remove the user from the session.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10506) Initial set of hasLoogedOut flag when logging in
[
https://issues.apache.org/jira/browse/OFBIZ-10506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-10506:
--
Attachment: OFBIZ-10506.patch
> Initial set of hasLoogedOut flag when logging in
>
>
> Key: OFBIZ-10506
> URL: https://issues.apache.org/jira/browse/OFBIZ-10506
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-10506.patch
>
>
> When setting up a new OFBiz with loadAll all the user logins are initially
> created with the flag {{hasLoggedOut}} set to null.
> This causes problems, when the method {{isUserLoggedIn}} from {{LoginWorker}}
> is used, since this checks if the flag is not null or N, and if it is null or
> not N it will remove the user from the session.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OFBIZ-10506) Initial set of hasLoogedOut flag when logging in
Dennis Balkir created OFBIZ-10506:
-
Summary: Initial set of hasLoogedOut flag when logging in
Key: OFBIZ-10506
URL: https://issues.apache.org/jira/browse/OFBIZ-10506
Project: OFBiz
Issue Type: Bug
Components: framework
Reporter: Dennis Balkir
Attachments: OFBIZ-10506.patch
When setting up a new OFBiz with loadAll all the user logins are initially
created with the flag {{hasLoggedOut}} set to null.
This causes problems, when the method {{isUserLoggedIn}} from {{LoginWorker}}
is used, since this checks if the flag is not null or N, and if it is null or
not N it will remove the user from the session.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10495) Rendering different HTML container types with ScreenRenderer
[
https://issues.apache.org/jira/browse/OFBIZ-10495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561630#comment-16561630
]
Dennis Balkir commented on OFBIZ-10495:
---
Hi [~deepak.dixit],
all other things looked good to me.
Thanks for reviewing!
> Rendering different HTML container types with ScreenRenderer
>
>
> Key: OFBIZ-10495
> URL: https://issues.apache.org/jira/browse/OFBIZ-10495
> Project: OFBiz
> Issue Type: Improvement
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-10495.patch, OFBIZ-10495_modular_container.patch
>
>
> This patch will add an type-parameter to the start and end render macros and
> methods of HTML containers.
> With this it is possible to not only use {{}} containers, but also use,
> for example, HTML5's {{}} .
> Simply by using
> {code:xml}
>
>
>
>
> {code}
> the renderer will render the container element as the given type.
> If type is left empty, it will always use it's fallback {{}}, and
> because of this no existing screen in OFBiz needs to be changed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10495) Rendering different HTML container types with ScreenRenderer
[
https://issues.apache.org/jira/browse/OFBIZ-10495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561588#comment-16561588
]
Dennis Balkir commented on OFBIZ-10495:
---
Hi [~deepak.dixit],
I checked mine before uploading, with my solution you could pass any value as
type and it would be recognized too.
But I appreciate the changes you made, since I didn't know of some of these
files, that also had to be changed, like for example {{FoScreenMacroLibrary}}.
The only thing I don't really understand, is your changed part in
{{HtmlScreenMacroLibrary}}. I understand, that this is easier, because type is
set with {{div}} as default, which is a lot better than my solution, but at
some point you used this:
{code:xml}
<#macro renderContainerEnd type="div">
{code}
In this you used {{div}} as a variable, but I don't see where you get it from?
Maybe some mistyping or I just don't get it, maybe you can explain this to me?
:D
> Rendering different HTML container types with ScreenRenderer
>
>
> Key: OFBIZ-10495
> URL: https://issues.apache.org/jira/browse/OFBIZ-10495
> Project: OFBiz
> Issue Type: Improvement
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-10495.patch, OFBIZ-10495_modular_container.patch
>
>
> This patch will add an type-parameter to the start and end render macros and
> methods of HTML containers.
> With this it is possible to not only use {{}} containers, but also use,
> for example, HTML5's {{}} .
> Simply by using
> {code:xml}
>
>
>
>
> {code}
> the renderer will render the container element as the given type.
> If type is left empty, it will always use it's fallback {{}}, and
> because of this no existing screen in OFBiz needs to be changed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OFBIZ-10495) Rendering different HTML container types with ScreenRenderer
[
https://issues.apache.org/jira/browse/OFBIZ-10495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-10495:
--
Attachment: OFBIZ-10495_modular_container.patch
> Rendering different HTML container types with ScreenRenderer
>
>
> Key: OFBIZ-10495
> URL: https://issues.apache.org/jira/browse/OFBIZ-10495
> Project: OFBiz
> Issue Type: Improvement
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: OFBIZ-10495_modular_container.patch
>
>
> This patch will add an type-parameter to the start and end render macros and
> methods of HTML containers.
> With this it is possible to not only use {{}} containers, but also use,
> for example, HTML5's {{}} .
> Simply by using
> {code:xml}
>
>
>
>
> {code}
> the renderer will render the container element as the given type.
> If type is left empty, it will always use it's fallback {{}}, and
> because of this no existing screen in OFBiz needs to be changed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OFBIZ-10495) Rendering different HTML container types with ScreenRenderer
Dennis Balkir created OFBIZ-10495:
-
Summary: Rendering different HTML container types with
ScreenRenderer
Key: OFBIZ-10495
URL: https://issues.apache.org/jira/browse/OFBIZ-10495
Project: OFBiz
Issue Type: Improvement
Reporter: Dennis Balkir
Attachments: OFBIZ-10495_modular_container.patch
This patch will add an type-parameter to the start and end render macros and
methods of HTML containers.
With this it is possible to not only use {{}} containers, but also use,
for example, HTML5's {{}} .
Simply by using
{code:xml}
{code}
the renderer will render the container element as the given type.
If type is left empty, it will always use it's fallback {{}}, and because
of this no existing screen in OFBiz needs to be changed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10331) Improve Order
[ https://issues.apache.org/jira/browse/OFBIZ-10331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547509#comment-16547509 ] Dennis Balkir commented on OFBIZ-10331: --- Hi Deepak, I will take another look at the patch for ShowCart and provide a better solution, if necessary, asap. Thanks > Improve Order > - > > Key: OFBIZ-10331 > URL: https://issues.apache.org/jira/browse/OFBIZ-10331 > Project: OFBiz > Issue Type: Sub-task > Components: order >Affects Versions: Trunk >Reporter: Dennis Balkir >Assignee: Deepak Dixit >Priority: Minor > Attachments: OFBIZ-10221-order.template.entry.OrderHeaderInfo.patch, > OFBIZ-10221-order.template.entry.OrderHeaderInfo.patch, > OFBIZ-10221_common-theme.template.includes.GenericLink.patch, > OFBIZ-10221_order.template.entry.CheckInits.patch, > OFBIZ-10221_order.template.entry.ChooseCatalog.patch, > OFBIZ-10221_order.template.entry.ChooseCatalog2.patch, > OFBIZ-10221_order.template.entry.OrderAgreements.patch, > OFBIZ-10221_order.template.entry.OrderEntryTabBar.patch, > OFBIZ-10221_order.template.entry.OrderShortcuts.patch, > OFBIZ-10221_order.template.entry.cart.ShowCart.patch, > OFBIZ-10221_order.template.entry.catalog.AdvancedSearch.patch, > OFBIZ-10221_order.template.entry.catalog.KeywordSearchBox.patch, > OFBIZ-10221_order.template.order.FindOrders.patch, > OFBIZ-10221_order.template.order.OrderList.patch, > OFBIZ-10221_order.template.order.OrderStats.patch, > OFBIZ-10331_order.template.entry.cart.PromoCode.patch, > OFBiz-10221_order.template.order.OrderContactInfo.patch, > OFBiz-10221_order.template.order.OrderInfo.patch, > OFBiz-10221_order.template.order.OrderItems.patch, > OFBiz-10221_order.template.order.OrderPaymentInfo.patch, > OFBiz-10221_order.template.order.OrderShippingInfo.patch, Sélection_156.png > > > All improvements for layout and structure for the Order-Application -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-9164) Refactor ContentWorkerInterface methods signatures
[
https://issues.apache.org/jira/browse/OFBIZ-9164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16542996#comment-16542996
]
Dennis Balkir commented on OFBIZ-9164:
--
Hi [~jacques.le.roux],
I found a mistake, which results in an Nullpointer.
If you go here: https://demo-trunk.ofbiz.apache.org/catalog/control/main then
open the lookup on the left for category id, click the first category (20111)
and then click on search, you will be prompted with this:
{{java.lang.IllegalArgumentException: Error running script at location
[component://product/groovyScripts/catalog/find/KeywordSearch.groovy]:
java.lang.NullPointerException}}
This is the result of the changes you made here, to be specific in
{{CategoryContentWrapper}} and {{ContentWorker}}.
The following code is the problem:
{code:java}
getProductCategoryContentAsText(null, productCategory, prodCatContentTypeId,
locale, mimeTypeId, delegator, dispatcher, outWriter, false);}}
{code}
This gives {{null}} as the value for the dispatcher, which is then used here
inside of {{getProductCategoryContentAsText}}:
{code:java}
ContentWorker.renderContentAsText(dispatcher,
categoryContent.getString("contentId"), outWriter, inContext, locale,
mimeTypeId, null, null, cache);
{code}
The problem is, that the method {{renderContentAsText}} as a result of your
changes uses the dispatcher to get the delegator:
{code:java}
public static void renderContentAsText(LocalDispatcher dispatcher, String
contentId, Appendable out, Map templateContext,
Locale locale, String mimeTypeId, String partyId, String
roleTypeId, boolean cache) throws GeneralException, IOException {
Delegator delegator = dispatcher.getDelegator();
GenericValue content = ContentWorker.findContentForRendering(delegator,
contentId, locale, partyId, roleTypeId, cache);
ContentWorker.renderContentAsText(dispatcher, content, out,
templateContext, locale, mimeTypeId, cache, null);
}
{code}
Because the dispatcher is a given {{null}} value at this point, this results in
a nullpointer.
> Refactor ContentWorkerInterface methods signatures
> --
>
> Key: OFBIZ-9164
> URL: https://issues.apache.org/jira/browse/OFBIZ-9164
> Project: OFBiz
> Issue Type: Sub-task
> Components: content, framework, lucene, order, party, product,
> workeffort
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: 17.12.01
>
> Attachments: OFBIZ-9164 DataResourceWorker.java.patch,
> OFBIZ-9164.patch
>
>
> While working on OFBIZ-6919 which was built on R13.07 I stumbled upon an
> issue due to r1652852 where Adrian improved the cacheKey in
> FormFactory.getFormFromLocation() by adding a delegator reference (Tenants).
> Actually I'm not even sure it was done at r1652852 because Adrian did not
> maintain the FormFactory svn history.
> Anyway, to make a long story short I had to introduce a DispatchContext
> parameter when calling FormFactory.readFormDocument() when the code from
> R13.07 only passed a null.
> This had an impact in the hierarchy tree because
> FormFactory.readFormDocument() was called in DataResourceWorker class, where
> the new code was called from renderDataResourceAsText(). So I instead of only
> passing a Delegator I decided to pass only a LocalDispatcher parameter in
> renderDataResourceAsText(), since we can get the Delegator from the
> LocalDispatcher. Doing so it had an impact on the renderDataResourceAsText
> hierarchy tree ending in DataResourceWorkerInterface and all related.
> I finally decided to apply the same ["Change Method Signature" refactoring
> pattern|http://refactoring.com/catalog/addParameter.html] to all cases
> related to ContentWorkerInterface. No need to pass a delegator when you have
> LocalDispatcher!
> Here I attach a patch for review, I'll commit in few days
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OFBIZ-10476) Fix / Remove Compdoc?
Dennis Balkir created OFBIZ-10476: - Summary: Fix / Remove Compdoc? Key: OFBIZ-10476 URL: https://issues.apache.org/jira/browse/OFBIZ-10476 Project: OFBiz Issue Type: Bug Components: content Reporter: Dennis Balkir While creating a theme and looking for not correctly styled elements I came across "some" not functional links and buttons in Compdoc. This module seems not to be finished or working properly, because most of the times, the buttons inside the appbar produce errors or just empty pages. Even when searching for existing elements and then clicking on them to examine or edit them will mostly create an error (example: go to compdoc, search for template child, click edit on some random found element -> error). Sometimes the menu which is included inside the appbar, mostly the menu called "tree", need the contentId for the buttons to work. Including this menu while creating a new entry will result in every button not working and throwing an error, except the edit button, which will produce a completely empty page. Those things appear all over the module, trying some button or clicking some link resulted in an error screen more than it resulted in something actually working. This should either be fixed or removed, if this doesn't has a real purpose at all. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-10475) Missing Import in CmsEditAddPrep.groovy
[
https://issues.apache.org/jira/browse/OFBIZ-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Balkir updated OFBIZ-10475:
--
Attachment:
OFBIZ-10475_applications.content.groovyScripts.cms.CmsEditAddPrep.patch
> Missing Import in CmsEditAddPrep.groovy
> ---
>
> Key: OFBIZ-10475
> URL: https://issues.apache.org/jira/browse/OFBIZ-10475
> Project: OFBiz
> Issue Type: Bug
> Components: content
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments:
> OFBIZ-10475_applications.content.groovyScripts.cms.CmsEditAddPrep.patch
>
>
> When going to Content > CMS and then clicking one of the items that are shown
> in the table, most of the times an error will show up.
> This is because, there is an missing import of {{UtilFormatOut}} in
> {{CmsEditAddPrep.groovy}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10475) Missing Import in CmsEditAddPrep.groovy
[
https://issues.apache.org/jira/browse/OFBIZ-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16542766#comment-16542766
]
Dennis Balkir commented on OFBIZ-10475:
---
I added the import and provided a patch for it. This seems to fix the problem.
> Missing Import in CmsEditAddPrep.groovy
> ---
>
> Key: OFBIZ-10475
> URL: https://issues.apache.org/jira/browse/OFBIZ-10475
> Project: OFBiz
> Issue Type: Bug
> Components: content
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments:
> OFBIZ-10475_applications.content.groovyScripts.cms.CmsEditAddPrep.patch
>
>
> When going to Content > CMS and then clicking one of the items that are shown
> in the table, most of the times an error will show up.
> This is because, there is an missing import of {{UtilFormatOut}} in
> {{CmsEditAddPrep.groovy}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OFBIZ-10475) Missing Import in CmsEditAddPrep.groovy
Dennis Balkir created OFBIZ-10475:
-
Summary: Missing Import in CmsEditAddPrep.groovy
Key: OFBIZ-10475
URL: https://issues.apache.org/jira/browse/OFBIZ-10475
Project: OFBiz
Issue Type: Bug
Components: content
Reporter: Dennis Balkir
When going to Content > CMS and then clicking one of the items that are shown
in the table, most of the times an error will show up.
This is because, there is an missing import of {{UtilFormatOut}} in
{{CmsEditAddPrep.groovy}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-2364) Competitors & Partners - Sales Force Automation component
[ https://issues.apache.org/jira/browse/OFBIZ-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16542707#comment-16542707 ] Dennis Balkir commented on OFBIZ-2364: -- Hi [~jacques.le.roux], since you were the last person commented on this, I will address this to you :) Do you, or anyone else, knows the current status of this? I just noticed, that the in the SFAAppbar there is a menu-point called "Competitors & Partners", which is labeled disabled and has no proper link in it. Is this still in development, or is this a dead feature? > Competitors & Partners - Sales Force Automation component > - > > Key: OFBIZ-2364 > URL: https://issues.apache.org/jira/browse/OFBIZ-2364 > Project: OFBiz > Issue Type: New Feature > Components: marketing >Affects Versions: Trunk > Environment: Mac OS X >Reporter: Vikas Mayur >Priority: Minor > Attachments: SFA Competitors & Partners.patch > > > Competitors and Partners will be parties (generally PartyGroup) and are > related to other items including Accounts, Opportunities, and so on. > The screens for Competitor would include: Competitor Home, Accounts, > Opportunities. > The screens for Partner would include: Partner Home, Accounts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-7598) Empty header row should not render if list to render in file is empty
[ https://issues.apache.org/jira/browse/OFBIZ-7598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540280#comment-16540280 ] Dennis Balkir commented on OFBIZ-7598: -- Hi Jacques, I didn't see the button at first, too. But now that I have found it (I didn't knew this existed to be honest), applying the patch worked. I tested it on some entity searches and it looks like it is working fine: * for no found entries, no header * for found entries it shows the header and the found entries Looks like it works fine for one found entry, too > Empty header row should not render if list to render in file is empty > - > > Key: OFBIZ-7598 > URL: https://issues.apache.org/jira/browse/OFBIZ-7598 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Suraj Khurana >Assignee: Suraj Khurana >Priority: Major > Fix For: Upcoming Branch > > Attachments: Image 002.png, OFBIZ-7598.patch, OFBIZ-7598.patch, > OFBIZ-7598.patch, OFBIZ-7598.patch, OFBIZ-7598.patch, OFBIZ-7598.png > > > If list inside form doesn't contain data, then header row should not render > from better UI perspective and proper message should be shown to user. > Please refer screenshot for details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-7598) Empty header row should not render if list to render in file is empty
[
https://issues.apache.org/jira/browse/OFBIZ-7598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539959#comment-16539959
]
Dennis Balkir commented on OFBIZ-7598:
--
I see, there truly was a misunderstanding.
I wanted to try it, but as I mentioned before in this issue, I could not fully
apply it.
My comment from the 4th:
{quote}Hi Suraj Khurana,
I tried to apply the patch via eclipse using an up-to-date trunk branch, but
there seems to be a difference in the file
themes/common-theme/template/macro/HtmlFormMacroLibrary.ftl, which results in
some incompability.
Can you please check for that?
Thanks{quote}
> Empty header row should not render if list to render in file is empty
> -
>
> Key: OFBIZ-7598
> URL: https://issues.apache.org/jira/browse/OFBIZ-7598
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Suraj Khurana
>Priority: Major
> Fix For: Upcoming Branch
>
> Attachments: Image 002.png, OFBIZ-7598.patch, OFBIZ-7598.patch,
> OFBIZ-7598.patch, OFBIZ-7598.patch, OFBIZ-7598.patch, OFBIZ-7598.png
>
>
> If list inside form doesn't contain data, then header row should not render
> from better UI perspective and proper message should be shown to user.
> Please refer screenshot for details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10464) Improve Accounting -AP
[ https://issues.apache.org/jira/browse/OFBIZ-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539797#comment-16539797 ] Dennis Balkir commented on OFBIZ-10464: --- I already created a Jira for AR: OFBIZ-10469 > Improve Accounting -AP > -- > > Key: OFBIZ-10464 > URL: https://issues.apache.org/jira/browse/OFBIZ-10464 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Dennis Balkir >Priority: Minor > Attachments: accounting-ap_main-page.patch > > > I found some structural differences while looking on accounting-ap -> main. > While all the other screenlets on such pages are nested inside the > surrounding div-containers, these ones are actually inside a table, which > then is inside the normally surrounding divs. > > This makes styling for new themes difficult and should be changed, since it > is an exception in the normally used structure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-7598) Empty header row should not render if list to render in file is empty
[ https://issues.apache.org/jira/browse/OFBIZ-7598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539795#comment-16539795 ] Dennis Balkir commented on OFBIZ-7598: -- Hi Jacques, yes I mean with the now reverted patch. I just specified this, because you asked for it :) > Empty header row should not render if list to render in file is empty > - > > Key: OFBIZ-7598 > URL: https://issues.apache.org/jira/browse/OFBIZ-7598 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Suraj Khurana >Assignee: Suraj Khurana >Priority: Major > Fix For: Upcoming Branch > > Attachments: Image 002.png, OFBIZ-7598.patch, OFBIZ-7598.patch, > OFBIZ-7598.patch, OFBIZ-7598.patch, OFBIZ-7598.patch, OFBIZ-7598.png > > > If list inside form doesn't contain data, then header row should not render > from better UI perspective and proper message should be shown to user. > Please refer screenshot for details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10464) Improve Accounting -AP
[
https://issues.apache.org/jira/browse/OFBIZ-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539623#comment-16539623
]
Dennis Balkir edited comment on OFBIZ-10464 at 7/11/18 6:34 AM:
Hi Jacques,
there is actually no difference seen, the only difference is in the code.
Before the change, the screenlets didn't just "sit" in the surrounding page
containers, but were nested inside a table.
Since this wasn't something I found anywhere else in the code, I removed it to
make the whole HTML more equal and more friendly to stylize.
The main page from AR had the same issue
You wrote:
{quote}
bq. Most of the times, the main screens just include .ftl files
Which is a pity. For instance you improved catalog/control/main with r1829700
for OFBIZ-10221. But then the fields are no longer aligned. So I have created
OFBIZ-10454. We should only use form widgets in the backend to easily keep
things concistent. Unfortunately we have a ton of legacy to change. Anyway,
thanks for your good work {quote}
This was just something I noticed while comparing the other main pages to the
ones from AR and AP.
I think the main problem is not even, that there are FTL files used instead of
form widgets, but that there is no rule for the HTML code. There are so many
differences inside the HTML code because of this and frequently there is the
same looking menu, or form, or button, but the code is totally different in 3
of 4 cases.
FTL has some advantages, that in my opinion can come in very handy, but there
have to be some conventions how certain elements should be implemented, so that
there is some consistency in the code
was (Author: dennis balkir):
Hi Jacques,
there is actually no difference seen, the only difference is in the code.
Before the change, the screenlets didn't just "sit" in the surrounding page
containers, but were nested inside a table.
Since this wasn't something I found anywhere else in the code, I removed it to
make the whole HTML more equal and more friendly to stylize.
The main page from AR had the same issue
> Improve Accounting -AP
> --
>
> Key: OFBIZ-10464
> URL: https://issues.apache.org/jira/browse/OFBIZ-10464
> Project: OFBiz
> Issue Type: Sub-task
> Components: accounting
>Affects Versions: Trunk
>Reporter: Dennis Balkir
>Priority: Minor
> Attachments: accounting-ap_main-page.patch
>
>
> I found some structural differences while looking on accounting-ap -> main.
> While all the other screenlets on such pages are nested inside the
> surrounding div-containers, these ones are actually inside a table, which
> then is inside the normally surrounding divs.
>
> This makes styling for new themes difficult and should be changed, since it
> is an exception in the normally used structure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10464) Improve Accounting -AP
[ https://issues.apache.org/jira/browse/OFBIZ-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539623#comment-16539623 ] Dennis Balkir edited comment on OFBIZ-10464 at 7/11/18 6:28 AM: Hi Jacques, there is actually no difference seen, the only difference is in the code. Before the change, the screenlets didn't just "sit" in the surrounding page containers, but were nested inside a table. Since this wasn't something I found anywhere else in the code, I removed it to make the whole HTML more equal and more friendly to stylize. The main page from AR had the same issue was (Author: dennis balkir): Hi Jacques, there is actually no difference seen, the only difference is in the code. Before the change, the screenlets didn't just "sit" in the surrounding page containers, but were nested inside a table. Since this wasn't something I found anywhere else in the code, I removed it to make the whole HTML more equal and more friendly to stylize. The main page from AR had the same issue > Improve Accounting -AP > -- > > Key: OFBIZ-10464 > URL: https://issues.apache.org/jira/browse/OFBIZ-10464 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Dennis Balkir >Priority: Minor > Attachments: accounting-ap_main-page.patch > > > I found some structural differences while looking on accounting-ap -> main. > While all the other screenlets on such pages are nested inside the > surrounding div-containers, these ones are actually inside a table, which > then is inside the normally surrounding divs. > > This makes styling for new themes difficult and should be changed, since it > is an exception in the normally used structure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10464) Improve Accounting -AP
[ https://issues.apache.org/jira/browse/OFBIZ-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539623#comment-16539623 ] Dennis Balkir commented on OFBIZ-10464: --- Hi Jacques, there is actually no difference seen, the only difference is in the code. Before the change, the screenlets didn't just "sit" in the surrounding page containers, but were nested inside a table. Since this wasn't something I found anywhere else in the code, I removed it to make the whole HTML more equal and more friendly to stylize. The main page from AR had the same issue > Improve Accounting -AP > -- > > Key: OFBIZ-10464 > URL: https://issues.apache.org/jira/browse/OFBIZ-10464 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: Trunk >Reporter: Dennis Balkir >Priority: Minor > Attachments: accounting-ap_main-page.patch > > > I found some structural differences while looking on accounting-ap -> main. > While all the other screenlets on such pages are nested inside the > surrounding div-containers, these ones are actually inside a table, which > then is inside the normally surrounding divs. > > This makes styling for new themes difficult and should be changed, since it > is an exception in the normally used structure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10470) Inconsistent screenlet-title containers
[
https://issues.apache.org/jira/browse/OFBIZ-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539620#comment-16539620
]
Dennis Balkir commented on OFBIZ-10470:
---
Hi Jacques,
yes you are right, the screenlets I mentioned are included as FTL files.
I don't think that it will be that easy, to use form widgets all over OFBiz,
since FTL files are used so frequently, but at least we can make some kind of
convention, that specifies what kind of screenlet titles we are using.
These can also be used in the FTL files and for that the HTML code will be more
equal.
Especially if something new is introduced, the commiter can look for these
convention and change the title if necessary.
> Inconsistent screenlet-title containers
> ---
>
> Key: OFBIZ-10470
> URL: https://issues.apache.org/jira/browse/OFBIZ-10470
> Project: OFBiz
> Issue Type: Improvement
>Reporter: Dennis Balkir
>Priority: Minor
>
> Through the OFBiz-Backend there is some inconsistency in the use of
> screenlet-titles.
> The title is normally nested inside this:
> {code:html}
>
>
>
> {code}
> But the title itself differs throughout the. backend quite often.
> As far as I have seen, there are 3 main kinds of title:
> # {code:html}
>
>
> Title
> {code}
> # {code:html}
>
>
> Title
> {code}
> # {code:html}
>
>
>
> Title
> {code}
> All three variants can be found right here:
> https://demo-trunk.ofbiz.apache.org/ordermgr/control/orderentry
> ({{li}} is used in the {{left}}-container, {{h3}} is used for "Create Sales
> Order" and {{div}} is used for the other screenlets)
> Wouldn't it be better to limit this to one kind of container, and maybe style
> the differences (if wanted) through classes?
> Or maybe two containers, which then can be styled differently?
> The way it is now, with most of them looking the same anyway, it seems rather
> confusing than useful
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
