* Move the GitHub button next to the "Browse all created Builds" button.
Both belong to the same group of buttons and this is consistent with Testman.
* Change both to <a> tags that open the destination URL in a new window.
* Define a constant for the GitHub URL.
* Guard all inputs from parameters with htmlspecialchars() when they're inserted into page content.
* Implement a new function is_valid_redirect() to only redirect to non-empty local URLs with allowed characters.
Thanks a lot to Stanislav Motylkov for the bug reports and a first fix!
ONLINE-793
ONLINE-802
Apparently, it is important to pass an "id" field in provideSessionInfo.
Fortunately, this field expects the same format of 32 alphanumeric characters as we already have in the "roslogin_session_id" cookie.
ONLINE-796
This script is now able to migrate our entire user database to LDAP/RosLogin.
By filtering out users that have never participated in either Drupal, Forum, Wiki, or JIRA and are older than one month, it reduces
our user base from 47333 to 7428.
I'm open for comments and reviews until this goes live.
I want to use this opportunity to clean the user database from inactive users.
A user is considered inactive if it is older than a month and has never been active in either Drupal, MediaWiki, phpBB, or JIRA.
Consequently, deleting it would not cause any loss of information.
However, it keeps our future LDAP directory small and may fix possible name clashes due to the new stricter username rules.
This careful integration leaves most of the original prosilver skin unchanged.
It should be a piece of cake to redo these changes if necessary for a later phpBB version.
The RosLogin integration will be realized as a proper extension instead of code changes spread over hundreds of phpBB core files.
This finally enables us to move to the latest phpBB release and makes further upgrades straightforward.
git.reactos.org is under our own control and its URLs are guaranteed to remain stable.
Furthermore, the web server can access it much faster, which is important for the get_headers() call.
This one is much simpler than any other SSO module for Drupal, because:
* it replaces the Drupal login methods instead of offering an additional way of logging in, and
* it redirects Drupal forms (e.g. account registration, password reset) to RosLogin pages instead of capturing input from Drupal and calling SSO functions.
Consequently, an inline login box (like ours at the bottom page) needs to be replaced by a link to /roslogin/?p=login
- Redirect to the "username_sent" message also when no such E-Mail address exists in the directory.
This prevents disclosing the existence of a particular E-Mail address when using the SendUsername feature.
- Remove unused globals.
- Use uppercase boolean values consistently.
RosLogin is a simple user Self-Service and Single-Sign-On system for a single site
(such as *.reactos.org) written in PHP and licensed under AGPLv3 or later.
In contrast to CAS, OAuth, SAML or Shibboleth-based solutions, RosLogin is much more
lightweight due to its focus on a single site.
Each login sets a site-wide cookie, which is sufficient to identify a user on every
page of the domain and subdomains.
No Public-Key-Infrastructure or XML message passing needs to be set up for this.
While many Single-Sign-On solutions only provide Login and Logout functionality,
RosLogin also comes with a Self-Service that handles registrations, user data changes,
and forgotten credentials.
Finally, PHP web applications like MediaWiki are first-class citizens for RosLogin.
They can easily get information about the currently logged in user by instantiating
`RosLogin` and calling the `isLoggedIn` and `getUserInformation` methods, thereby
implementing SSO functionality.
RosLogin also takes care to only allow user names that do not conflict with the user
name constraints of popular PHP applications.
By managing the entire user information in an LDAP directory (inetOrgPerson schema),
RosLogin additionally allows a basic integration of applications without writing any
custom code.
The migration to RosLogin will decouple our user database from the CMS, easing a later
migration to any other CMS, and put an end to weirdnesses such as the 30 minute delay
for account changes in JIRA.
That means, the first "Running stage 1" line is never counted and an ideal result would only report 2 reboots (into stage 2 and stage 3).
This gets the logic back to what we had in SVN times.
svn path=/trunk/; revision=1012
This is still not really what I want, but less of a hack and causes no harm if we ever migrate the database to another server.
svn path=/trunk/; revision=1008
I consider this a bug given that even mysqldump is now unable to identically export and reimport this table..
At least, the people at Stackoverflow have found this way around it: https://stackoverflow.com/a/31865524
svn path=/trunk/; revision=1007
