<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 4, 2013 at 5:26 PM, Hylke Bons <span dir="ltr"><<a href="mailto:hbons@redhat.com" target="_blank">hbons@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
It seems that most of us are happy with the wireframes for the Unified<br>
Push Server admin UI. I've used the feedback to make a few small<br>
changes:<br>
<a href="https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_push_server_admin_ui.png" target="_blank">https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_push_server_admin_ui.png</a></blockquote>
<div><br></div><div style>Nice!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
The next step is to look at the the missing features like the user<br>
management and authentication. It would be good to have a discussion<br>
about this, and I have some questions too.<br>
<br>
If I understand things correctly, the Push Server can run "standalone"<br>
or as a component in JBoss AS (or something else).</blockquote><div><br></div><div style>UnifiedPush-Server is deployed as a WAR (standalone)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So we'll need a UI<br>
for user management when we run standalone, but one that can be disabled<br>
and be plugged in by different existing auth systems that are running on<br>
the server or somewhere else.<br></blockquote><div><br></div><div>there is NO connection to LDAP etc planed (for now)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Some questions that come to mind:<br>
<br>
How is the server bootstrapped? And how is the initial user account<br>
configured? </blockquote><div><br></div><div style>I thought about initially storing a developer user "Admin:Admin" user in the database.</div><div style>Users are asked to modify (or even delete) that.</div><div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The most essential basic role would be to access the UI and<br>
to configure push notifications (and one to add other (admin) users).<br>
Are there any other roles that we should be considering? Things that<br>
should be disabled for some users?<br></blockquote><div><br></div><div style>Perhaps. I, initially, had only the "developer" role in mind: allowed for all the things.</div><div style>We could (later?) add some Admin that has the right to create devs etc</div>
<div style><br></div><div style><br></div><div style>-Matthias</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
<br>
Hylke<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a>
</div></div>