Re: git commit workflow for ofbiz
+1 for Git! Jacopo On Sat, Jan 12, 2019 at 1:01 PM Michael Brohl wrote: > Hi all, > > I'd like to revive this discussion again. > > Personally, I am now working with git for a few years and almost all > customer and company related projects have moved to git over time. In > the beginning, I found git complicated and less straight forward, a bit > like Adrian mentioned in [1]. But once I have understood the main > principles and get used to it, I won't like to switch back to svn ever > since. > > In my opinion, using git would make things much easier for > collaboration. Taher thoroughly described them in the inital thread > message. > > An important point for me would be that we could prevent premature > commits just to get things to be tested. Features which take some time > to be worked on or tested can be in separate branches which can be > updated with the main branch constantly. > > So, from my point of view, we should again have a disussion and/or vote > to see if the overall opinions have changed and if we could move to git. > > Thanks, > > Michael > > > [1] http://markmail.org/message/m4z5b5qevqx7n6u7 > > Am 24.10.15 um 10:23 schrieb Taher Alkhateeb: > > Hello Everyone, > > > > I refer to the discussion about moving to git initiated by Hans Bakker > back in April. After a long, long discussion followed by a vote the > community agreed that we should develop a more elaborate and formal > workflow to vote on, as the initial vote was not detailed enough. Based on > that, I have proposed a workflow to see if people are interested in it. But > the topic just slowly died out. > > > > The links to both threads are listed below. I understand that there was > a lot of interest in the community as the thread was really long. I would > like to revive the discussion and see if people are still interested in > implementing / amending the proposed workflow if they find it appealing. > > > > discussion and vote thread : > http://ofbiz.markmail.org/message/ldo77qz34kte4gat?q=move+to+git+from:%22Hans+Bakker%22+list:org.apache.ofbiz.dev=1 > > > > workflow proposition thread : > http://ofbiz.markmail.org/message/nkthnbsgt37orynu?q=git+commit+workflow > > > > Taher Alkhateeb > > - Original Message - > > > > From: "Taher Alkhateeb" > > To: dev@ofbiz.apache.org > > Sent: Wednesday, 24 June, 2015 5:25:31 PM > > Subject: Re: git commit workflow for ofbiz > > > > > > Hi Jacques, > > > > Very good read, thank you for sharing. > > > > The person who wrote complaining about gitflow (I think Adam Ruka) makes > a good point. He prefers linear to branched history. I do not mind branched > history myself as I know how to navigate it but to each his own. Either > way, The workflow can be accomplished the way he suggested by rebasing > rather than merging the history and making a few other changes like > dropping "develop". It is up to community to decide, and git is flexible > enough to accommodate any model. > > > > Taher Alkhateeb > > > > - Original Message - > > > > From: "Jacques Le Roux" > > To: dev@ofbiz.apache.org > > Sent: Wednesday, 24 June, 2015 4:19:42 PM > > Subject: Re: git commit workflow for ofbiz > > > > Le 24/06/2015 14:06, Jacques Le Roux a écrit : > >> If you get a chance to read these articles I highly recommend them > >> > >> > http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/ > > Of course don't miss > http://www.alwaysagileconsulting.com/organisation-antipattern-release-feature-branching/ > > > > Jacques > > > >> http://endoflineblog.com/gitflow-considered-harmful > >> http://endoflineblog.com/follow-up-to-gitflow-considered-harmful > >> > >> Jacques > >> > >> > >> Le 12/05/2015 19:28, Adam Heath a écrit : > >>> Nice. This is quite thorough. There is an option missing. SVN > committers who use git offline. In this case, their changes can be > published as > >>> primary SVN branches, for collaboration.. See OFBIZ-6271 in JIRA, and > as an SVN branch, for an example. > >>> > >>> I've read through most of what follows, and am in agreement, but I'm > dealing with hardware problems, so I need to let it sink in first. > >>> > >>> On 05/12/2015 04:43 AM, Taher Alkhateeb wrote: > Hi everyone, > > This email refers to the thread for voting to move to git (link at > bottom) in which the vote decision was to delay and elaborate on the > workflow > first. I am not well versed in ASF guidelines and appreciate any help > and feedback and also please note some of the below is my opinion and not > necessarily 100% factual. > > ## First, identified problems > > 1. patches can quickly be outdated if not applied quickly > 2. big patches are hard to audit and not desired nor preferred and It > is hard to break big patches to smaller ones because if any of those patches > is outdated or modified then everything needs to be re-patched > 3. to collaborate with other people (non-committers) freely on big > features,
Re: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality
+1 to disabling it by default. We could consider, rather than adding a new configuration flag, to disable the feature if no secret is set in the configuration files (and do not provide a secret out of the box). Jacopo On Sat, Jan 19, 2019 at 12:57 PM Michael Brohl wrote: > Hi all, > > during my work in [1] I realized that the OOTB JWT authorization / > single sign on is switched on by default. The logic to retrieve the > secret key uses a default if there is no configuration in SystemProperty > or security.properties. > > This makes it easy to prepare a JWT (e.g. by using [2] or [3]) and login > using a guessed userLoginId and this token (which can be retrieved from > the code). > > I think we should secure this so that this cannot be done in an OOTB > setting with the following additions: > > 1. make it configurable through a property which is initially turned > off. I think thi is better than commenting the preprocessor in/out > because it can be better integrated in (custom) configuration mechanisms. > > 2. don't use a default secret key if none is provided. The > user/administrator must explicitly set a secret key and should know what > he is doing then. > > 3. don't proceed if no secret key can be found (do not attempt a login > using the JWT) > > > I think that we should turn this feature off by default for the > following reasons: > > 1. it opens up a security hole if the user does not remove the > checkJWTLogin preprocessor (see above) > > 2. the functionality to have a single sign on between two OFBiz > instances will only be used in rare cases (I think). It is only designed > for this special case and cannot be used for standard single sign on > scenarios with other systems. > > 3. if it is not used, it will still try to read the authorization > header, key etc. *on every request* > > > What do think? > > Regards, > > Michael > > > [1] https://issues.apache.org/jira/browse/OFBIZ-10814 > > [2] https://jwt.io/ > > [3] http://jwtbuilder.jamiekurtz.com/ > > > > >
Re: svn commit: r1851203 - in /ofbiz/ofbiz-framework/branches/release17.12: ./ framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java framework/webapp/src/main/java/org/apache/ofbiz/web
Hi Jacques, When there is one web app with the empty mount point (i.e. deployed on root), the auto-login cookie will not work for that particular webapp due to the change in the path of the cookie from "/" to "/" + applicationName. Because the system will try to find the cookie at the "/" but it is actually at "/" + applicationName. Thanks & Regards -- Deepak Nigam HotWax Systems Pvt. Ltd On Sun, Jan 13, 2019 at 7:13 PM wrote: > Author: jleroux > Date: Sun Jan 13 13:43:44 2019 > New Revision: 1851203 > > URL: http://svn.apache.org/viewvc?rev=1851203=rev > Log: > "Applied fix from trunk for revision: 1851200" > > r1851200 | jleroux | 2019-01-13 14:31:13 +0100 (dim. 13 janv. 2019) | 11 > lignes > > Reverted: Impossible secure and autologin cookie names when mountpoint > contains > a slash inside its name > (OFBIZ-10766) > > In my previous commit I reverted the initial change. As I said in the Jira > I had a second look and it's better to fix the problem at the root as I > did > initially. > > I wrote in my previous commit: "This method is used in other places where > the > name should not be changed." I checked there are no issues changing > slashes to > underscores in the cookies names anywhere. > > > Modified: > ofbiz/ofbiz-framework/branches/release17.12/ (props changed) > > ofbiz/ofbiz-framework/branches/release17.12/framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java > > ofbiz/ofbiz-framework/branches/release17.12/framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/LoginWorker.java > > Propchange: ofbiz/ofbiz-framework/branches/release17.12/ > > -- > --- svn:mergeinfo (original) > +++ svn:mergeinfo Sun Jan 13 13:43:44 2019 > @@ -10,4 +10,4 @@ > /ofbiz/branches/json-integration-refactoring:1634077-1635900 > /ofbiz/branches/multitenant20100310:921280-927264 > /ofbiz/branches/release13.07:1547657 > > -/ofbiz/ofbiz-framework/trunk:1819499,1819598,1819800,1819805,1819811,1819947,1820038,1820262,1820374-1820375,1820441,1820457,1820644,1820658,1820790,1820823,1820949,1820966,1821012,1821036,1821112,1821115,1821144,1821186,1821219,1821226,1821230,1821386,1821613,1821628,1821965,1822125,1822310,1822377,1822383,1822393,1823467,1823562,1823876,1824314,1824316,1824732,1824803,1824847,1824855,1825192,1825211,1825216,1825233,1825450,1826374,1826502,1826592,1826671,1826674,1826780,1826805,1826938,1826997,1827439,1828255,1828316,1828346,1828424,1828512,1828514,1829690,1830936,1831074,1831078,1831234,1831608,1831831,1832577,1832662,1832756,1832800,1832944,1833173,1833211,1834181,1834191,1834736,1835235,1835887,1835891,1835953,1835964,1836144,1836871,1837857,1838032,1838256,1838381,1840189,1840199,1840828,1841657,1841662,1842372,1842921,1843225,1843893,1844943,1845418,1845420,1845466,1845544,1845552,1845558,1845933,1845995,1846097,1846107,1846214,1846594,1846632,1847398,1847478,1847670,1847715, > > > 1847890,1848263,1848336,1848386,1848398,1848441,1848444,1848447,1848449,1848467,1848469,1848745,1848849-1848850,1849021,1849191,1849193,1849275,1849467,1849528,1849540,1849567,1849693,1850015,1850023,1850530,1850647,1850685,1850694,1850914,1850918,1850948,1850953,1851006,1851068,1851074,1851130,1851158,1851163 > > +/ofbiz/ofbiz-framework/trunk:1819499,1819598,1819800,1819805,1819811,1819947,1820038,1820262,1820374-1820375,1820441,1820457,1820644,1820658,1820790,1820823,1820949,1820966,1821012,1821036,1821112,1821115,1821144,1821186,1821219,1821226,1821230,1821386,1821613,1821628,1821965,1822125,1822310,1822377,1822383,1822393,1823467,1823562,1823876,1824314,1824316,1824732,1824803,1824847,1824855,1825192,1825211,1825216,1825233,1825450,1826374,1826502,1826592,1826671,1826674,1826780,1826805,1826938,1826997,1827439,1828255,1828316,1828346,1828424,1828512,1828514,1829690,1830936,1831074,1831078,1831234,1831608,1831831,1832577,1832662,1832756,1832800,1832944,1833173,1833211,1834181,1834191,1834736,1835235,1835887,1835891,1835953,1835964,1836144,1836871,1837857,1838032,1838256,1838381,1840189,1840199,1840828,1841657,1841662,1842372,1842921,1843225,1843893,1844943,1845418,1845420,1845466,1845544,1845552,1845558,1845933,1845995,1846097,1846107,1846214,1846594,1846632,1847398,1847478,1847670,1847715, > > > 1847890,1848263,1848336,1848386,1848398,1848441,1848444,1848447,1848449,1848467,1848469,1848745,1848849-1848850,1849021,1849191,1849193,1849275,1849467,1849528,1849540,1849567,1849693,1850015,1850023,1850530,1850647,1850685,1850694,1850914,1850918,1850948,1850953,1851006,1851068,1851074,1851130,1851158,1851163,1851200 > > Modified: > ofbiz/ofbiz-framework/branches/release17.12/framework/base/src/main/java/org/apache/ofbiz/base/util/UtilHttp.java > URL: >
Re: svn commit: r1851805 - in /ofbiz/ofbiz-framework/trunk/framework/entityext: minilang/EntitySyncServices.xml servicedef/services.xml src/main/java/org/apache/ofbiz/entityext/synchronization/EntityS
love :)
On 22/01/2019 12:51, arunpati...@apache.org wrote:
Author: arunpatidar
Date: Tue Jan 22 11:51:46 2019
New Revision: 1851805
URL: http://svn.apache.org/viewvc?rev=1851805=rev
Log:
Fixed: EntitySync Push and Pull functionalities
(OFBIZ-10818)
Removed unneccessary service implementation and used entity-auto
Fixed some create/update code block in the flow
Modified:
ofbiz/ofbiz-framework/trunk/framework/entityext/minilang/EntitySyncServices.xml
ofbiz/ofbiz-framework/trunk/framework/entityext/servicedef/services.xml
ofbiz/ofbiz-framework/trunk/framework/entityext/src/main/java/org/apache/ofbiz/entityext/synchronization/EntitySyncContext.java
Modified:
ofbiz/ofbiz-framework/trunk/framework/entityext/minilang/EntitySyncServices.xml
URL:
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/entityext/minilang/EntitySyncServices.xml?rev=1851805=1851804=1851805=diff
==
---
ofbiz/ofbiz-framework/trunk/framework/entityext/minilang/EntitySyncServices.xml
(original)
+++
ofbiz/ofbiz-framework/trunk/framework/entityext/minilang/EntitySyncServices.xml
Tue Jan 22 11:51:46 2019
@@ -40,27 +40,6 @@ under the License.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Modified:
ofbiz/ofbiz-framework/trunk/framework/entityext/servicedef/services.xml
URL:
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/entityext/servicedef/services.xml?rev=1851805=1851804=1851805=diff
==
--- ofbiz/ofbiz-framework/trunk/framework/entityext/servicedef/services.xml
(original)
+++ ofbiz/ofbiz-framework/trunk/framework/entityext/servicedef/services.xml Tue
Jan 22 11:51:46 2019
@@ -200,22 +200,28 @@ under the License.
-
+
+
+Update EntitySync
+
+
+
+
+
+
Create EntitySyncHistory
-
+
-
+
Update EntitySyncHistory
-
+
Delete EntitySyncHistory
Modified:
ofbiz/ofbiz-framework/trunk/framework/entityext/src/main/java/org/apache/ofbiz/entityext/synchronization/EntitySyncContext.java
URL:
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/framework/entityext/src/main/java/org/apache/ofbiz/entityext/synchronization/EntitySyncContext.java?rev=1851805=1851804=1851805=diff
==
---
ofbiz/ofbiz-framework/trunk/framework/entityext/src/main/java/org/apache/ofbiz/entityext/synchronization/EntitySyncContext.java
(original)
+++
ofbiz/ofbiz-framework/trunk/framework/entityext/src/main/java/org/apache/ofbiz/entityext/synchronization/EntitySyncContext.java
Tue Jan 22 11:51:46 2019
@@ -302,11 +302,17 @@ public class EntitySyncContext {
public void createInitialHistory() throws SyncDataErrorException,
SyncServiceErrorException {
String errorMsg = "Not running EntitySync [" + entitySyncId + "], could
not create EntitySyncHistory";
try {
-Map initialHistoryRes = dispatcher.runSync("createEntitySyncHistory", UtilMisc.toMap("entitySyncId",
entitySyncId, "runStatusId", "ESR_RUNNING", "beginningSynchTime", this.currentRunStartTime, "lastCandidateEndTime",
this.currentRunEndTime, "userLogin", userLogin));
+Timestamp startDateTime = UtilDateTime.nowTimestamp();
+Map initialHistoryRes = dispatcher.runSync("createEntitySyncHistory", UtilMisc.toMap("entitySyncId",
entitySyncId, "runStatusId", "ESR_RUNNING", "beginningSynchTime", this.currentRunStartTime, "lastCandidateEndTime",
this.currentRunEndTime, "startDate", startDateTime, "userLogin", userLogin));
if (ServiceUtil.isError(initialHistoryRes)) {
throw new SyncDataErrorException(errorMsg, null, null,
initialHistoryRes, null);
}
this.startDate = (Timestamp) initialHistoryRes.get("startDate");
+
+Map result = dispatcher.runSync("updateEntitySync",
UtilMisc.toMap("entitySyncId", entitySyncId, "lastHistoryStartDate", this.startDate,
"userLogin", userLogin));
+if (ServiceUtil.isError(result)) {
+throw new SyncDataErrorException(errorMsg, null, null, result,
null);
+}
} catch (GenericServiceException e) {
throw new SyncServiceErrorException(errorMsg, e);
}
@@ -768,43 +774,51 @@ public class EntitySyncContext {
// store latest result on EntitySync, ie update
lastSuccessfulSynchTime, should run in own tx
Map updateEsRunResult = dispatcher.runSync("updateEntitySyncRunning",
Re: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality
Le 22/01/2019 à 10:11, Michael Brohl a écrit :
3. if it is not used, it will still try to read the authorization
header, key etc. *on every request*
Yes, that's not a problem it's only few ms (if even) as long as there is no JWT
passed. Else all the other pre-processors would also be concerned...
The problem is: without explicitely switching it off, it will parse a provided JWT token on every request *even if you don't want to use the SSO
feature*. You might want to use the Authorization: Bearer header for other scenarios than SSO. Implementing a REST service for example,
which is the reason I stumbled upon this.
Implicitely turning the feature on when the header is present is not a good idea, we should separate concerns.
Ha I see your point now, I had still my code in mind. Before I was only doing a
request.getHeader("Authorization");
And that was also the reason I wanted a simple Authorization header, that's
fast.
In one the first implementations I remember I used to have a properties to decide if the JWT was on or off for the same reason. I removed it after
because it was not costly with the code above
I agree it makes sense again now
Thanks
Jacques
Re: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality
Hi Jacques, inline... Am 22.01.19 um 09:51 schrieb Jacques Le Roux: Hi Michael, It seems there is a consensus for disabling the JWT feature OOTB and it makes sense after testing with Postman. Thanks, Jacques. Rest inline: Le 22/01/2019 à 07:43, Michael Brohl a écrit : 2. the functionality to have a single sign on between two OFBiz instances will only be used in rare cases (I think). It is only designed for this special case and cannot be used for standard single sign on scenarios with other systems. If we make this feature implicitly non-operational, what about showing it in example? I guess showing it should depend of the property which switch on/off the JWT feature. Yes, this would be another improvement. 3. if it is not used, it will still try to read the authorization header, key etc. *on every request* Yes, that's not a problem it's only few ms (if even) as long as there is no JWT passed. Else all the other pre-processors would also be concerned... The problem is: without explicitely switching it off, it will parse a provided JWT token on every request *even if you don't want to use the SSO feature*. You might want to use the Authorization: Bearer header for other scenarios than SSO. Implementing a REST service for example, which is the reason I stumbled upon this. Implicitely turning the feature on when the header is present is not a good idea, we should separate concerns. I'm going to provide an enhanced patch for all this. Thanks, Michael smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality
Hi Michael, It seems there is a consensus for disabling the JWT feature OOTB and it makes sense after testing with Postman. Rest inline: Le 22/01/2019 à 07:43, Michael Brohl a écrit : 2. the functionality to have a single sign on between two OFBiz instances will only be used in rare cases (I think). It is only designed for this special case and cannot be used for standard single sign on scenarios with other systems. If we make this feature implicitly non-operational, what about showing it in example? I guess showing it should depend of the property which switch on/off the JWT feature. 3. if it is not used, it will still try to read the authorization header, key etc. *on every request* Yes, that's not a problem it's only few ms (if even) as long as there is no JWT passed. Else all the other pre-processors would also be concerned... Jacques
