[Owncloud] ampache and invalid login

[Martin Mazur]

Hello,


I'm using owncloud 4.5.6 and tried to use ampache. It it working fine  
when I use my admin account but when I try to use my normal account I  
always get "invalid login". My client is amarok on debian testing and  
iAmpache on iOS 6 - both with the same result. Owncloud log does not  
have any hint on this.


Any idea where to start looking for the reason?

Thanks & best regards

Martin

--
Martin Mazur
mar...@barbara-und-martin.de





___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] Reverse Proxy with Apache

[maex]

hi have you tried

RewriteRule ^/owncloud(.*)$ http://internalserver.local/owncloud/$1 [L,P]

the match part  of the rule without ending slash.

so the ruile should macht at ../owncloud/ and ../owncloud too.

Matthias

On 19.02.2013 10:38, Tobias Brunner wrote:
> Hi,
>
> I'd like to configure a reverse proxy for ownCloud.
> OC is running on an internal server, not accessible over the internet:
> http://internalserver.local/owncloud. Therefore I've created the
> following Apache rewrite rule:
>
> RewriteRule ^/owncloud/(.*)$ http://internalserver.local/owncloud/$1
> [L,P]
>
> This works well if I use the URL http://externalserver.tld/owncloud/
> but not for http://externalserver.tld/owncloud (without the ending
> slash). Does anyone have an advice how to create a rewrite rule which
> also works without an ending slash?
>
> Cheers,
> Tobias
> ___
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>

___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID

[Arthur Schiwon]

On 02/19/2013 02:55 PM, Andreas Ergenzinger wrote:


On Tuesday, February 19, 2013 12:36 CET, Arthur Schiwon  
wrote:

  I configure CN as the display name attribute. But display
names are not unique. So it's not possible to find the right user.




It's true that display names are not unique. But would it help to number
them? You would end up with
John Doe
John Doe (2)
John Doe (3)

→ i see the problem, but forcing unqiueness for display names does not
look like a solution for me

A way would be to add an (optional) second attribute that may be
displayed in brackets, e.g. displayName + mail
John Doe (j...@doe.net)
John Doe (john@example.biz)

I am open for ideas and suggestions on this.


I can understand the desire to keeps things simple and general by not enforcing 
uniqueness of display names, but your own example illustrates the need for 
human-readable, unique identifiers. If all users data is coming from the same 
source, e.g. a single LDAP server, then it is possible to guarantee uniqueness 
by selecting an appropriate attribute. In such a scenario, the email address is 
probably the best choice for the display name.

The problems start once you combine different user bases with duplicate 
attributes values, or once you permit users to change their display names, 
because either one can lead to name clashes. Editable display names are 
especially problematic from a security standpoint, since some users may 
intentionally try to change their display name, in the hope of being mistakenly 
granted access to private data. I used to think that just checking for existing 
display names would be enough to prevent problems, but users may try to grab 
the default display name (e.g. the email address) of a potential user who does 
not have an OC account, yet, creating trouble down the road.

So, for highest security, display names should be globally unique and 
unchangeable.


Depends on where you tackle it. If you ensure uniqueness on LDAP side, 
you are not getting a problem on ownCloud as long as you don't use other 
user backends (which may have other problems). In some cases it is 
necessary that display names can be modified, for instance when family 
names change, titles needs to be added, or if job positions, departments 
or likes are included in the display name.


When you take a step back and look at a bigger picture, some backends do 
not provide user lists (IMAP, WebDAV) so you cannot see which names are 
already in use. Shifting it all to ownCloud core means drawbacks as 
stated above.


The LDAP backend really takes care that _internal_ names stay unique. As 
it was up to 4.5 they also were used as display names which did not make 
all people happy, because of the limitations.


Note that not every available user backend takes care of unique names 
(ownCloud's internal does, IMAP or WebDAV don't afaik).


Also note that display names of LDAP users cannot be changed from within 
ownCloud as we do not write to LDAP.



If that is not the case, then we have to rely on the suggested displayName + 
mail, which effectively creates a third user identifier, let's call this the 
unique display name (UDN). Due to the mentioned security issues, the UDN should 
be used pretty much everywhere instead of the simple display name, which makes 
the non-unique display name superfluous.

Considering the display name just as the editable part of the UDN, without ever 
using it on its own, would require extensive code changes but seems like  a 
reasonable compromise.


The LDAP configuration gives you pretty much free hand of what you 
define as display name. Take an exisiting attribute of your choice or 
extend you directory with one. It gives you a lot of power and flexibility.




BTW thank you Arthur for answering my other mail.


Welcome

Cheers
Arthur



Cheers
Andreas
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] Updating theme from owncloud 4 to 5

[Jan-Christoph Borchardt]

Hey Stefan,

I don’t know if there’s any such update handbook. We don’t really focus on
theming, except for business customers.

ownCloud is not a blogging engine where templates can be used to alter the
style of your website and reflect how you want it to look to readers. It is
a tool which aims to help people get work done and get out of their way as
much as possible, through simple and unobtrusive design. I believe that can
be best achieved by focusing on one great core design which everyone is
committed to make easy to use and understand.

This is partly a problem because there are not many designers active in our
community – though the design sense is growing more and more. I would
really love to have you contributing to the core ownCloud design. What are
the problems you see with the current interface & interaction design? How
would you fix them? Can we see your themes in action somewhere?






On Mon, Feb 18, 2013 at 11:49 PM, development  wrote:

> Hi list,
>
> I have written some custom themes for owncloud 4 which i would like to
> update to owncloud 5.
> Is there any update handbook where the changes are documented between
> oc::4 and oc::5?
>
> Oh.. i should probably mention that these are truly custom themes, which
> do not only override css but also quite a lot of *core* templates.
>
> Hope to hear some answer soon.
>
> Kind regards,
>
>
> Stefan Nagtegaal
>
> ___
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>
>
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID

[Tornóci László]

On 02/19/2013 04:38 PM, Andreas Ergenzinger wrote:


On Tuesday, February 19, 2013 15:09 CET, Frank Karlitschek
 wrote:

An admin can disable the option for users to change the display
name. I depends on the user scenario if this is useful and save or


Very good. I agree that editable display names can be a source of all 
kinds of problems.



not. In case you use a directory like LDAP then we rely on a
properly configured useraccounts in it including unique and
understandable display names.

The scenario of different LDAP servers is interesting but I'm not
sure if it is in the scope of ownCloud to resolve naming collisions
in his case. This can and should be solved in the LDAP
configuration.

Frank


I completely agree with you there. In such an environment naming
collisions can only be prevented by a prudent configuration. However,
I still don't see the point of non-unique display names. Due to the
potential for confusion, we need a different way to distinguish users
on the screen. Unfortunately the only standardized option available
at the moment is the login name which may be "pop55307",
"d41d8cd98f00b204e9800998ecf8427e", or something equally opaque. I
think we need a better alternative and requiring display names to be
unique is the most simple solution I can think of.


If I understand correctly, you can set any attribute in LDAP as display 
name. So you can set it up any way you like. E.g. I plan to create a new 
LDAP attribute like this: LDAP display name + LDAP department name. You 
only have a problem, if you don't have write access to LDAP.


Yours: Laszlo



___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

[Owncloud] And suddenly it was four apps...

[Christian Reiner]

Hi, 
to complete the collection I just ported my "FluXX-Compensator (Y)" to OC 
version 5. Some of you have already seen a glimpse inside OC-4. However due to 
the upcoming release a port made sense. Because of the layout changes 
contained in OC-5 the apps implementation could be simplyfied quite a lot. 
Actually the app now works without known problems. So I thought I could as 
well release it...

There is no configuration, simply use it: 
click the handles to move header or navigation panel in and out of view. Click 
and drag to move the handles to wherever you like, this is persistant. 

All style changes and animations are purely css based. Just the initialization 
of the handles is implemented in a simple js snippet. 
There are still a few glitches left in some apps layout. This app is able to 
compensate those glitches, I implemented a simple generic strategy for this. 
Anyone who likes to update or complete that collection will easily find his 
way around. All rules can be anchored to a few style classes set on the 
documents html node. 

Have fun!
Christian Reiner (arkascha) (arkascha)
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID

[Andreas Ergenzinger]

 
On Tuesday, February 19, 2013 15:09 CET, Frank Karlitschek  
wrote: 
> An admin can disable the option for users to change the display name. I 
> depends on the user scenario if this is useful and save or not. In case you 
> use a directory like LDAP then we rely on a properly configured useraccounts 
> in it including unique and understandable display names. 
> 
> The scenario of different LDAP servers is interesting but I'm not sure if it 
> is in the scope of ownCloud to resolve naming collisions in his case. This 
> can and should be solved in the LDAP configuration.
> 
> Frank
> 
I completely agree with you there. In such an environment naming collisions can 
only be prevented by a prudent configuration. However, I still don't see the 
point of non-unique display names. Due to the potential for confusion, we need 
a different way to distinguish users on the screen. Unfortunately the only 
standardized option available at the moment is the login name which may be 
"pop55307", "d41d8cd98f00b204e9800998ecf8427e", or something equally opaque. I 
think we need a better alternative and requiring display names to be unique is 
the most simple solution I can think of.

Andreas
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID

[Frank Karlitschek]

On 19.02.2013, at 08:55, Andreas Ergenzinger 
 wrote:

> 
> On Tuesday, February 19, 2013 12:36 CET, Arthur Schiwon  
> wrote: 
>>> I configure CN as the display name attribute. But display
>>> names are not unique. So it's not possible to find the right user.
> 
>> 
>> It's true that display names are not unique. But would it help to number 
>> them? You would end up with
>> John Doe
>> John Doe (2)
>> John Doe (3)
>> 
>> → i see the problem, but forcing unqiueness for display names does not 
>> look like a solution for me
>> 
>> A way would be to add an (optional) second attribute that may be 
>> displayed in brackets, e.g. displayName + mail
>> John Doe (j...@doe.net)
>> John Doe (john@example.biz)
>> 
>> I am open for ideas and suggestions on this.
> 
> I can understand the desire to keeps things simple and general by not 
> enforcing uniqueness of display names, but your own example illustrates the 
> need for human-readable, unique identifiers. If all users data is coming from 
> the same source, e.g. a single LDAP server, then it is possible to guarantee 
> uniqueness by selecting an appropriate attribute. In such a scenario, the 
> email address is probably the best choice for the display name.
> 
> The problems start once you combine different user bases with duplicate 
> attributes values, or once you permit users to change their display names, 
> because either one can lead to name clashes. Editable display names are 
> especially problematic from a security standpoint, since some users may 
> intentionally try to change their display name, in the hope of being 
> mistakenly granted access to private data. I used to think that just checking 
> for existing display names would be enough to prevent problems, but users may 
> try to grab the default display name (e.g. the email address) of a potential 
> user who does not have an OC account, yet, creating trouble down the road.
> 
> So, for highest security, display names should be globally unique and 
> unchangeable.
> 
> If that is not the case, then we have to rely on the suggested displayName + 
> mail, which effectively creates a third user identifier, let's call this the 
> unique display name (UDN). Due to the mentioned security issues, the UDN 
> should be used pretty much everywhere instead of the simple display name, 
> which makes the non-unique display name superfluous.
> 
> Considering the display name just as the editable part of the UDN, without 
> ever using it on its own, would require extensive code changes but seems like 
>  a reasonable compromise.
> 
> BTW thank you Arthur for answering my other mail.
> 
> Cheers
> Andreas
> 

An admin can disable the option for users to change the display name. I depends 
on the user scenario if this is useful and save or not. In case you use a 
directory like LDAP then we rely on a properly configured useraccounts in it 
including unique and understandable display names. 

The scenario of different LDAP servers is interesting but I'm not sure if it is 
in the scope of ownCloud to resolve naming collisions in his case. This can and 
should be solved in the LDAP configuration.

Frank


___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID

[Andreas Ergenzinger]

 
On Tuesday, February 19, 2013 12:36 CET, Arthur Schiwon  
wrote: 
> >  I configure CN as the display name attribute. But display
> > names are not unique. So it's not possible to find the right user.

> 
> It's true that display names are not unique. But would it help to number 
> them? You would end up with
> John Doe
> John Doe (2)
> John Doe (3)
> 
> → i see the problem, but forcing unqiueness for display names does not 
> look like a solution for me
> 
> A way would be to add an (optional) second attribute that may be 
> displayed in brackets, e.g. displayName + mail
> John Doe (j...@doe.net)
> John Doe (john@example.biz)
> 
> I am open for ideas and suggestions on this.

I can understand the desire to keeps things simple and general by not enforcing 
uniqueness of display names, but your own example illustrates the need for 
human-readable, unique identifiers. If all users data is coming from the same 
source, e.g. a single LDAP server, then it is possible to guarantee uniqueness 
by selecting an appropriate attribute. In such a scenario, the email address is 
probably the best choice for the display name.

The problems start once you combine different user bases with duplicate 
attributes values, or once you permit users to change their display names, 
because either one can lead to name clashes. Editable display names are 
especially problematic from a security standpoint, since some users may 
intentionally try to change their display name, in the hope of being mistakenly 
granted access to private data. I used to think that just checking for existing 
display names would be enough to prevent problems, but users may try to grab 
the default display name (e.g. the email address) of a potential user who does 
not have an OC account, yet, creating trouble down the road.

So, for highest security, display names should be globally unique and 
unchangeable.

If that is not the case, then we have to rely on the suggested displayName + 
mail, which effectively creates a third user identifier, let's call this the 
unique display name (UDN). Due to the mentioned security issues, the UDN should 
be used pretty much everywhere instead of the simple display name, which makes 
the non-unique display name superfluous.

Considering the display name just as the editable part of the UDN, without ever 
using it on its own, would require extensive code changes but seems like  a 
reasonable compromise.

BTW thank you Arthur for answering my other mail.

Cheers
Andreas
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] default reply to owncloud@kde.org header

[MJ Ray]

Jan-Christoph Borchardt 
> Sorry for the harsh tone, but we’re close to releasing ownCloud 5 and all
> of you people’s time is better spent testing and fixing it rather than in
> this thread. If you want to be awesome, help out!

Repasting the explanations of why List-* is better than screwing up
Reply-To from my sent-mail takes me almost no time - and if it stops
any other lists being broken, it'll save me and many others time later.

I'm also testing ownCloud on a development machine.  So far I think
the problems are either build, installation or configuration errors,
so for me to investigate, but if I nail any down to an actual bug,
I'll feed it back - but I can't help with github because I don't agree
to their registration terms, but that's been covered already.

Regards,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and library systems developer.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire (including development) at http://www.software.coop/
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] Are display names unique? and related questions

[Arthur Schiwon]

Hey,

display names are not unique.

getUsers returns internal names while getDisplayNames returns display names.

Internal names are unique.

Cheers
Arthur

On 02/18/2013 04:24 PM, Andreas Ergenzinger wrote:

Hello,

Since user selection for sharing and most other activities is supposed
to be based on the display name from now on, the answer to my question
should obviously be "yes". However, after looking at the OC_User class
as well as the associated user backend and interface classes, I am not
sure that this uniqueness is enforced anywhere.

Am I missing something, or do we need a displayNameExists($displayName)
function in the user interface?

I am also not sure about the future role of the getUsers($search = '',
$limit = null, $offset = null) method, apart from providing a list of
all users if no search parameter is specified. It seems to me that the
function is completely replaced by getDisplayNames($search = '', $limit
= null, $offset = null) in all other cases. Besides backward
compatibility, is there another reason for needing approximate search of
uids/login names?

Andreas
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] owncloud alpha 1 and LDAP entryUUID

[Arthur Schiwon]

On 02/19/2013 09:19 AM, Dirk Kastens wrote:

Hi,

the LDAP backend is now using the entyUUID attribute to store users.


(tech detail: the uuid attribute will be autodetected, e.g. AD uses a 
different one)



I
don't know if this is such a good idea. Now, if you share a file, the
entryUUID is displayed instead of the uid (see attached picture).


I believe it has already been fixed in master with 
https://github.com/owncloud/core/commit/bef48bad8b83b2826d6eb3397e3f22e8d20ba5f3



 And in
the user list of the admin interface you see the entryUUIDs as the
loginnames.


The label is ambiguous. The ownCloud user management uses the internal 
username as login name. For LDAP users the internal ownCloud name will 
be shown. Also, LDAP users do not have a unique or permanent login name, 
depending on the configuration (e.g. login via username and email adress).


Worth a bug report.


 I configure CN as the display name attribute. But display
names are not unique. So it's not possible to find the right user.


It's true that display names are not unique. But would it help to number 
them? You would end up with

John Doe
John Doe (2)
John Doe (3)

→ i see the problem, but forcing unqiueness for display names does not 
look like a solution for me


A way would be to add an (optional) second attribute that may be 
displayed in brackets, e.g. displayName + mail

John Doe (j...@doe.net)
John Doe (john@example.biz)

I am open for ideas and suggestions on this.

Helpful to have this as a bug report, too.

Thanks for pointing at it!

Cheers
Arthur



Dirk


___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud


___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] webinstaller installs old 4.0.12

[Frank Karlitschek]

Should be fixed now.
Sorry.

Frank

On 19.02.2013, at 04:13, Mark Ziegler  wrote:

> Post from forum:
> 
> "thanks for the new web installer it saves me a very painful upload, it works 
> geat but seems to instal an old version?
> 
> when using the web instaler link on http://owncloud.org/support/install/ 
> (Install ownCloud Server 4.5.6)
> I downloaded: 
> https://download.owncloud.com/download/ ... ncloud.php
> which gets :
> https://download.owncloud.org/download/ ... latest.zip
> which currently (2012-02-18) seems to be 4.0.12
> 
> Thanks,
> 
> Johannes"
> 
> Forum url: http://forum.owncloud.org/viewtopic.php?t=8370&p=20344#p20344
> 
> Just verified it myself. Same behaviour.
> 
> Cheers,
> Mark
> ___
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud

___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

[Owncloud] Reverse Proxy with Apache

[Tobias Brunner]

Hi,

I'd like to configure a reverse proxy for ownCloud.
OC is running on an internal server, not accessible over the internet: 
http://internalserver.local/owncloud. Therefore I've created the 
following Apache rewrite rule:


RewriteRule ^/owncloud/(.*)$ http://internalserver.local/owncloud/$1 
[L,P]


This works well if I use the URL http://externalserver.tld/owncloud/ 
but not for http://externalserver.tld/owncloud (without the ending 
slash). Does anyone have an advice how to create a rewrite rule which 
also works without an ending slash?


Cheers,
Tobias
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

Re: [Owncloud] Sync to OC instances

[Polonevich Ivan]

  
  
Probably you should try using Unison
  (for sync users data in two way ) + Mysql master-master
  replication.  I use it in my two servers instance. 
  
  On 19.02.13, 0:50, Tobias Brunner wrote:

Hi,
  
  
  Is it possible to sync two OC server instances and if yes, how to
  do it?
  
  I'd like to have two OC servers in sync so that clients can
  connect to the fastest one (at the office to the local one, on the
  road to one which has a good internet connection)... Maybe run
  mirall on one of these servers? Any other suggestions?
  
  
  Cheers,
  
  Tobias
  
  ___
  
  Owncloud mailing list
  
  Owncloud@kde.org
  
  https://mail.kde.org/mailman/listinfo/owncloud
  



-- 
 
Ivan Polonevich 
System Administrator 
Wargaming.net | GameStream 
 
  Email: i_polonev...@wargaming.net
  
  skype: jonilover 
  Phone: +375 44 7277680 
   
  

___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

[Owncloud] webinstaller installs old 4.0.12

[Mark Ziegler]

Post from forum:

"thanks for the new web installer it saves me a very painful upload, it 
works geat but seems to instal an old version?


when using the web instaler link on http://owncloud.org/support/install/ 
(Install ownCloud Server 4.5.6)

I downloaded:
https://download.owncloud.com/download/ ... ncloud.php 


which gets :
https://download.owncloud.org/download/ ... latest.zip 


which currently (2012-02-18) seems to be 4.0.12

Thanks,

Johannes"

Forum url: http://forum.owncloud.org/viewtopic.php?t=8370&p=20344#p20344

Just verified it myself. Same behaviour.

Cheers,
Mark
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud

[Owncloud] owncloud alpha 1 and LDAP entryUUID

[Dirk Kastens]

Hi,

the LDAP backend is now using the entyUUID attribute to store users. I 
don't know if this is such a good idea. Now, if you share a file, the 
entryUUID is displayed instead of the uid (see attached picture). And in 
the user list of the admin interface you see the entryUUIDs as the 
loginnames. I configure CN as the display name attribute. But display 
names are not unique. So it's not possible to find the right user.


Dirk
<>

smime.p7s
Description: S/MIME Kryptografische Unterschrift
___
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud