[xwiki-users] store.xwiki.com - domain reported and verified as serving malware by CISCO

[Miroslav Galajda]

Hi,

when checking for extension updates in xwiki administration, the extension
updater lists some errors.

After some investigation, I've found that xwiki is trying to call some REST
api pointing to url like this:
https://store.xwiki.com/xwiki/rest/repository/extensions/[URL_ENDING_PART]
where the [URL_ENDING_PART] was one of the following examples found in the
log:
- com.google.code.findbugs%3Aannotations/versions/api
-
org.xwiki.platform%3Axwiki-platform-blog-ui/versions?requireTotalHits=true&start=0&number=-1
-
org.xwiki.contrib.ldap%3Aldap-authenticator/versions?requireTotalHits=true&start=0&number=-1

The reason for the above listed https calls is due to our proxy that is
inspecting every outgoing communication and has denied the requests to
store.xwiki.com. The proxy uses CISCO list of untrusted web sites which
says this:

Reason: BLOCK-MALWARE
Threat Type: othermalware
Threat Reason: Domain reported and verified as serving malware. Identified
as malicious IP. Identified as malicious domain or URL.
Notification: WBRS

Can be this domain trusted or not? Is it a false threat or not?

Is it legal when xwiki calls the API at https://store.xwiki.com?

Thank you

Re: [xwiki-users] store.xwiki.com - domain reported and verified as serving malware by CISCO

[Vincent Massol]

Hi Miroslav,

> On 9 May 2017, at 10:34, Miroslav Galajda  wrote:
> 
> Hi,
> 
> when checking for extension updates in xwiki administration, the extension
> updater lists some errors.
> 
> After some investigation, I've found that xwiki is trying to call some REST
> api pointing to url like this:
> https://store.xwiki.com/xwiki/rest/repository/extensions/[URL_ENDING_PART]
> where the [URL_ENDING_PART] was one of the following examples found in the
> log:
> - com.google.code.findbugs%3Aannotations/versions/api
> -
> org.xwiki.platform%3Axwiki-platform-blog-ui/versions?requireTotalHits=true&start=0&number=-1
> -
> org.xwiki.contrib.ldap%3Aldap-authenticator/versions?requireTotalHits=true&start=0&number=-1
> 
> The reason for the above listed https calls is due to our proxy that is
> inspecting every outgoing communication and has denied the requests to
> store.xwiki.com. The proxy uses CISCO list of untrusted web sites which
> says this:
> 
> Reason: BLOCK-MALWARE
> Threat Type: othermalware
> Threat Reason: Domain reported and verified as serving malware. Identified
> as malicious IP. Identified as malicious domain or URL.
> Notification: WBRS
> 
> Can be this domain trusted or not? Is it a false threat or not?
> 
> Is it legal when xwiki calls the API at https://store.xwiki.com?

Is it can be trusted and it’s legal. Our governance at 
http://dev.xwiki.org/xwiki/bin/view/Community/Governance allows the top 
sponsoring company to list its extension repository in the xwiki configuration 
by default (you can override this if you wish in your xwiki.properties file, 
search for the extension.repositories property).

FYI ATM the top sponsoring company is XWiki SAS (http://xwiki.com), see 
https://www.xwiki.org/xwiki/bin/view/Main/Supporters/SponsoringCompanies/. It 
currently provides two paying extensions that are advertised on 
http://extensions.xwiki.org/ in the “Sponsored Extensions” section.

Thanks
-Vincent

> Thank you

Re: [xwiki-users] Attachments get deleted permanently

[Hamster]

That looks a lot like the bug i reported ages ago...

https://jira.xwiki.org/browse/XWIKI-10234?filter=-2




--
View this message in context: 
http://xwiki.475771.n2.nabble.com/Attachments-get-deleted-permanently-tp7603734p7603800.html
Sent from the XWiki- Users mailing list archive at Nabble.com.

[xwiki-users] Error saving Notifications Preferences

[Marcio Barreto]

Hi,

I have just installed xwiki 9.3 and I am having problems with the
notification settings. I've used tomcat9, mysql14 on centos 6.9.

On the user profile, Notifications Preferences option I cant change the
notification settings. Every time i toggle the option I get an error:
"Failed to save your settings"

and get this error on the server:
mai 09, 2017 11:19:02 AM org.restlet.engine.application.StatusFilter
doHandle
WARNING: Exception or error caught in status service
java.lang.IllegalStateException: The Web form cannot be parsed as no fresh
content is available. If this entity has been already read once, caching of
the entity is required
at org.restlet.engine.util.FormUtils.parse(FormUtils.java:272)
at org.restlet.data.Form.(Form.java:88)
at
org.xwiki.rest.internal.representations.objects.FormUrlEncodedObjectReader.readFrom(FormUrlEncodedObjectReader.java:82)
at
org.xwiki.rest.internal.representations.objects.FormUrlEncodedObjectReader.readFrom(FormUrlEncodedObjectReader.java:52)
at
org.restlet.ext.jaxrs.internal.wrappers.provider.SingletonProvider.readFrom(SingletonProvider.java:304)
at
org.restlet.ext.jaxrs.internal.wrappers.params.EntityGetter.getValue(EntityGetter.java:109)
at
org.restlet.ext.jaxrs.internal.wrappers.params.ParameterList.get(ParameterList.java:1090)
at
org.restlet.ext.jaxrs.internal.wrappers.AbstractMethodWrapper.internalInvoke(AbstractMethodWrapper.java:169)
at
org.restlet.ext.jaxrs.internal.wrappers.ResourceMethod.invoke(ResourceMethod.java:291)
at
org.restlet.ext.jaxrs.JaxRsRestlet.invokeMethod(JaxRsRestlet.java:1043)
at org.restlet.ext.jaxrs.JaxRsRestlet.handle(JaxRsRestlet.java:792)
at org.restlet.routing.Filter.doHandle(Filter.java:159)
at org.restlet.routing.Filter.handle(Filter.java:206)
at org.restlet.routing.Router.doHandle(Router.java:500)
at org.restlet.routing.Router.handle(Router.java:740)
at org.restlet.routing.Filter.doHandle(Filter.java:159)
at org.restlet.routing.Filter.handle(Filter.java:206)
at org.restlet.routing.Filter.doHandle(Filter.java:159)
at org.restlet.routing.Filter.handle(Filter.java:206)
at org.restlet.routing.Filter.doHandle(Filter.java:159)
at org.restlet.routing.Filter.handle(Filter.java:206)
at org.restlet.routing.Filter.doHandle(Filter.java:159)
at org.restlet.routing.Filter.handle(Filter.java:206)
at org.restlet.routing.Filter.doHandle(Filter.java:159)
at
org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:154)
at org.restlet.routing.Filter.handle(Filter.java:206)
at org.restlet.routing.Filter.doHandle(Filter.java:159)
at org.restlet.routing.Filter.handle(Filter.java:206)
at org.restlet.engine.ChainHelper.handle(ChainHelper.java:114)
at
org.restlet.engine.application.ApplicationHelper.handle(ApplicationHelper.java:75)
at org.restlet.Application.handle(Application.java:391)
at org.restlet.routing.Filter.doHandle(Filter.java:159)
at org.restlet.routing.Filter.handle(Filter.java:206)
at org.restlet.routing.Router.doHandle(Router.java:500)
at org.restlet.routing.Router.handle(Router.java:740)
at org.restlet.routing.Filter.doHandle(Filter.java:159)
at org.restlet.routing.Filter.handle(Filter.java:206)
at org.restlet.routing.Router.doHandle(Router.java:500)
at org.restlet.routing.Router.handle(Router.java:740)
at org.restlet.routing.Filter.doHandle(Filter.java:159)
at org.restlet.routing.Filter.handle(Filter.java:206)
at org.restlet.engine.ChainHelper.handle(ChainHelper.java:114)
at org.restlet.Component.handle(Component.java:391)
at org.restlet.Server.handle(Server.java:491)
at org.restlet.engine.ServerHelper.handle(ServerHelper.java:74)
at
org.restlet.engine.http.HttpServerHelper.handle(HttpServerHelper.java:153)
at
org.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:1031)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at
org.xwiki.wysiwyg.server.filter.XWikiContextInitializationFilter.doFilter(XWikiContextInitializationFilter.java:85)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt

Re: [xwiki-users] store.xwiki.com - domain reported and verified as serving malware by CISCO

[Miroslav Galajda]

Hi,

thank you for your explanation.

Best regards,
Mirec

On 9 May 2017 at 10:39, Vincent Massol  wrote:

> Hi Miroslav,
>
> > On 9 May 2017, at 10:34, Miroslav Galajda 
> wrote:
> >
> > Hi,
> >
> > when checking for extension updates in xwiki administration, the
> extension
> > updater lists some errors.
> >
> > After some investigation, I've found that xwiki is trying to call some
> REST
> > api pointing to url like this:
> > https://store.xwiki.com/xwiki/rest/repository/extensions/[
> URL_ENDING_PART]
> > where the [URL_ENDING_PART] was one of the following examples found in
> the
> > log:
> > - com.google.code.findbugs%3Aannotations/versions/api
> > -
> > org.xwiki.platform%3Axwiki-platform-blog-ui/versions?
> requireTotalHits=true&start=0&number=-1
> > -
> > org.xwiki.contrib.ldap%3Aldap-authenticator/versions?
> requireTotalHits=true&start=0&number=-1
> >
> > The reason for the above listed https calls is due to our proxy that is
> > inspecting every outgoing communication and has denied the requests to
> > store.xwiki.com. The proxy uses CISCO list of untrusted web sites which
> > says this:
> >
> > Reason: BLOCK-MALWARE
> > Threat Type: othermalware
> > Threat Reason: Domain reported and verified as serving malware.
> Identified
> > as malicious IP. Identified as malicious domain or URL.
> > Notification: WBRS
> >
> > Can be this domain trusted or not? Is it a false threat or not?
> >
> > Is it legal when xwiki calls the API at https://store.xwiki.com?
>
> Is it can be trusted and it’s legal. Our governance at
> http://dev.xwiki.org/xwiki/bin/view/Community/Governance allows the top
> sponsoring company to list its extension repository in the xwiki
> configuration by default (you can override this if you wish in your
> xwiki.properties file, search for the extension.repositories property).
>
> FYI ATM the top sponsoring company is XWiki SAS (http://xwiki.com), see
> https://www.xwiki.org/xwiki/bin/view/Main/Supporters/SponsoringCompanies/.
> It currently provides two paying extensions that are advertised on
> http://extensions.xwiki.org/ in the “Sponsored Extensions” section.
>
> Thanks
> -Vincent
>
> > Thank you
>
>

Re: [xwiki-users] [Proposal][UX] Feedback for Explicit Content Actions

[Ecaterina Moraru (Valica)]

Hi,

So after 2 weeks of available time to express opinions I have some
conclusions: we are going to implement P2.
I've created http://jira.xwiki.org/browse/XWIKI-14265
We are going to make sure to have a span around the labels so that they can
be easily hidden in custom skins.

We had 42 votes around the subject held on 4 channels, for more details see
http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaLabeledActions#HVoting
P2 had 65% of the votes, while P4 35%.

Thanks everyone for the votes
Caty

On Fri, Apr 28, 2017 at 12:36 PM, Mahomed Hussein 
wrote:

> > I’d go as far as saying that the labels could actually be distracting by
> taking more visual
> > space and catching your eyes when you look at the UI as a whole and want
> to focus on the
> > content.
>
> I totally agree with this about the UI and wasted space and distractions.
>
> > Now this could be minor and the advantages for the newcomers could be
> more important than the
> > small downside for returning users.
>
> Well newcomers just need to learn about the functions of the buttons by
> using them once or twice. Whereas the rest of us have to deal with the
> wasted space and distraction forever more :) Also, can't the concern about
> newcomers (and the introduction to the purpose of the buttons) be addressed
> with the tour application that now runs for new users?
>
> Honestly I don't think everyone is going to agree on this. Whatever the
> XWiki team chooses, will probably be fine. People will complain for a bit
> and just move on with life. So I think the team should just take the result
> from the poll and implement that as I think the topic could continue
> indefinitely :-)
>
>
> Kind regards,
>
>
>
>
> Mahomed Hussein
> Custodian Data Centre
> Email: maho...@custodiandc.com
> http://www.CustodianDC.com
>
> -Original Message-
> From: users [mailto:users-boun...@xwiki.org] On Behalf Of Vincent Massol
> Sent: 28 April 2017 09:02
> To: XWiki Users 
> Subject: Re: [xwiki-users] [Proposal][UX] Feedback for Explicit Content
> Actions
>
>
> > On 28 Apr 2017, at 09:57, Ecaterina Moraru (Valica) 
> wrote:
> >
> > On Fri, Apr 28, 2017 at 10:47 AM, Clément Aubin
> > 
> > wrote:
> >
> >> Hi,
> >>
> >> On 04/27/2017 11:58 AM, Ecaterina Moraru (Valica) wrote:
> >>> Some summary until now:
> >>> P2: Craig, Olivier
> >>> P4: Mahomed, Steffen, Jesse, Miroslav
> >>
> >> As a «fresh» user, I would prefer P2, mostly because I don’t think
> >> that every newcomer will have the intuition to look at the top-right
> >> corner of the page for its options. Adding labels allows for those
> >> three icons to be more visible.
> >>
> >>
> > From an usability perspective, having labels is unbeatable both for
> > new users and advanced users.
>
> I agree for new users but not for advanced. Users who’ve used those button
> just once know about them and don’t need the labels. I’d go as far as
> saying that the labels could actually be distracting by taking more visual
> space and catching your eyes when you look at the UI as a whole and want to
> focus on the content.
>
> Now this could be minor and the advantages for the newcomers could be more
> important than the small downside for returning users.
>
> Thanks
> -Vincent
>
> > We could also display the icons labels only if the user has the
> > «simple»
> >> user profile and remove them as soon as he becomes more advanced.
> >>
> >
> > Not sure about making this configurable. It's a simple decision, we
> > need to agree on a default. With this approach we make everything in
> > XWiki configurable.
> >
> > The advantage of reaching to newcomers is that in time they will also
> > become advanced users. We want to encourage user transformation. Also
> > I don't think users that start with a more explicit interface will
> > like the change after, since they will become accustomed to it.
> >
> > Thanks,
> > Caty
> >
> >
> >>
> >> Thanks,
> >>
> >> --
> >> Clément Aubin
> >> Web Developer Intern @XWiki SAS
> >> clement.au...@xwiki.com
> >> More about us at http://www.xwiki.com
>
>

[xwiki-users] Search icon disappeared in the menu

[genevieve.au...@telmatik.com]

Do you know how I can add the search icon in the menu?  The Search Suggest is
enable in the configuration.  The Search is visible in the main wiki but not
in the sub-wiki site.  

 

Thanks




--
View this message in context: 
http://xwiki.475771.n2.nabble.com/Search-icon-disappeared-in-the-menu-tp7603805.html
Sent from the XWiki- Users mailing list archive at Nabble.com.

Re: [xwiki-users] Search icon disappeared in the menu

[Vincent Massol]

Hi,

Verify that the "Solr Search Application" extension is installed in your 
subwiki.

Thanks
-Vincent

> On 9 May 2017, at 16:37, genevieve.au...@telmatik.com wrote:
> 
> Do you know how I can add the search icon in the menu?  The Search Suggest is
> enable in the configuration.  The Search is visible in the main wiki but not
> in the sub-wiki site.  
> 
>  
> 
> Thanks
> 
> 
> 
> 
> --
> View this message in context: 
> http://xwiki.475771.n2.nabble.com/Search-icon-disappeared-in-the-menu-tp7603805.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.

Re: [xwiki-users] Search icon disappeared in the menu

[genevieve.au...@telmatik.com]

Hi,

The Solr is installed.  I try to reindex the site and to set the search
suggest to No, than back to Yes without success...  
 

Thanks



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/Search-icon-disappeared-in-the-menu-tp7603805p7603807.html
Sent from the XWiki- Users mailing list archive at Nabble.com.

Re: [xwiki-users] Search icon disappeared in the menu

[Vincent Massol]

Hi,

From your screenshot it’s definitely not installed correctly and some wiki 
pages are missing.

Please reinstall the Solr Search app or import its XAR to get the wiki pages.

Thanks
-Vincent

> On 9 May 2017, at 17:23, genevieve.au...@telmatik.com wrote:
> 
> Hi,
> 
> The Solr is installed.  I try to reindex the site and to set the search
> suggest to No, than back to Yes without success...  
>  
> 
> Thanks
> 
> 
> 
> --
> View this message in context: 
> http://xwiki.475771.n2.nabble.com/Search-icon-disappeared-in-the-menu-tp7603805p7603807.html
> Sent from the XWiki- Users mailing list archive at Nabble.com.

Re: [xwiki-users] [Proposal][UX] Feedback for Visible Save buttons

[Ecaterina Moraru (Valica)]

Hi,

The initial proposal was about the fixed bottom position. For that we will
have https://jira.xwiki.org/browse/XWIKI-14162 issue
In order to have a bottom bar, we compacted the save options, for that we
will have the https://jira.xwiki.org/browse/XWIKI-14267

Thanks to everyone who responded in the survey. The results are available
at
https://docs.google.com/forms/d/1DM74hlXQQ22WVdqhYbGWyITWXTH5qgmKSMIrS3eHDKE/viewanalytics

The proposal we will implement is
http://design.xwiki.org/xwiki/bin/download/Proposal/IdeaVisibleSave/proposal9xCK.png

Initially I wanted to remove some buttons and reduce their number, but the
feedback was mixed, so this has been postponed, until we gather more usage
data or feedback.

Some conclusions:
- "Save & View" received 12 votes as used most often. Since it's also an
action that changes modes (takes the user to view) and is a final action,
it will be marked with primary state (blue).
- "Save" was also voted and voters were against remove it. Since it
received 12 votes and is related to save, it will be the next action. We
simplified the name from "Save&Continue" to "Save".
- "Preview" received just 4 votes, but we consider this action to be
directed towards newcomer users that need to be comfortable with their
changes and be able to preview them.
- "Cancel" was kept near the other actions in order to be consistent with
the other layout we have across XWiki. It will be displayed outside of the
button group.

Thanks,
Caty

On Thu, Apr 27, 2017 at 4:29 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> Sorry. The link was https://goo.gl/forms/QyG5eOM44rBkd3qk2
>
> On Thu, Apr 27, 2017 at 4:23 PM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
>
>> I've created this form to gather data about the buttons usage, in order
>> to make a proposal for the buttons location
>> https://docs.google.com/forms/d/e/1FAIpQLSeQwjxlFl321Ap97xKlYRcf-39wlG-
>> cJXXqM1nududfjo3KHQ/viewanalytics
>>
>> Hope everyone is comfortable with Google Forms.
>> Thanks,
>> Caty
>>
>>
>> On Thu, Apr 27, 2017 at 12:56 PM, Denis GERMAIN 
>> wrote:
>>
>>> Great proposition ! I like it.
>>>
>>> I see that the subject has also diverted to the fact that you can "save
>>> and
>>> continue" and "save and view". Some of our users are lost the first time
>>> as
>>> they click "save and continue" and don't understand why they are still in
>>> edit mode. Clarifying this would indeed be a good idea, even though they
>>> usually get the distinction quickly after that.
>>>
>>> Regards,
>>> Denis
>>>
>>> 2017-04-26 17:01 GMT+02:00 Ecaterina Moraru (Valica) >> >:
>>>
>>> > On Wed, Apr 26, 2017 at 5:41 PM, Craig Wright 
>>> wrote:
>>> >
>>> > > Hi Caty,
>>> > >
>>> > > I am a fan of “B”.
>>> > >
>>> > > I like the idea of putting the changelog and autosave options above
>>> on a
>>> > > preceding row. I would argue that for most users, their eyes only
>>> see the
>>> > > leftmost buttons as the functionally useful area. Thus putting
>>> Cancel on
>>> > > the far right effectively “hides” the button.
>>> > >
>>> >
>>> > Yes, the most visible buttons are the ones on the left side and that's
>>> the
>>> > purpose. We need people to see the Save button :)
>>> > Now, 'summary' functionality is not mandatory when editing and can
>>> also be
>>> > disabled from Administration - Editing.
>>> > Having it on a separate line is not an option since we initial idea of
>>> the
>>> > thread is to provide a fixed bottom bar, when the viewport is small. So
>>> > there are all on a single bar in order to be compact.
>>> >
>>> >
>>> > >
>>> > > For the purposes of mobile, I think it is acceptable to hide the
>>> > changelog
>>> > > and autosave options on small-screen resolutions. (Such as when I am
>>> > > editing from iPhone, I am highly unlikely to leave a changelog
>>> message
>>> > > anyway.)
>>> > >
>>> >
>>> > I haven't iterated much on the mobile version, but the mockup I have is
>>> > http://design.xwiki.org/xwiki/bin/download/Proposal/
>>> > IdeaVisibleSave/mobile.png
>>> > It can be improved, and as you said we could decide that on mobile we
>>> can
>>> > hide some functionality, but again hard to have stats to justify what
>>> is
>>> > used/needed or not.
>>> >
>>> > Thanks,
>>> > Caty
>>> >
>>> >
>>> > > FWIW, taborder should be the following:
>>> > >
>>> > > 1. Edit input
>>> > > 2. Changelog input
>>> > > 3. Save button
>>> > > 4. Preview button
>>> > > 5. Cancel button
>>> > > 6. Autosave option
>>> > >
>>> > > My $0.02. :)
>>> > >
>>> > > Thanks,
>>> > > Craig
>>> > >
>>> > > > On Apr 26, 2017, at 2:20 PM, Ecaterina Moraru (Valica) <
>>> > > vali...@gmail.com> wrote:
>>> > > >
>>> > > > Hi,
>>> > > >
>>> > > > On Wed, Apr 26, 2017 at 2:39 PM, Craig Wright >> > > > wrote:
>>> > > >
>>> > > >> Overall I like these changes. A couple of suggestions:
>>> > > >>
>>> > > >> No one in my community understands “Save and Continue” versus
>>> “Save
>>> > and
>>> > > >> View”. Dropping the “and