Skip to content
/ on_ruby Public

💎 ♦️ Whitelabel Site for Ruby Communities

Notifications You must be signed in to change notification settings

rughh/on_ruby

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

OnRuby

donate at patreon build Status vulnerability status

site status & uptime

Get in touch in our Slack Channel - join #on_ruby

Source for the Sites of the Ruby Communities:

Support OnRuby

The operation, development and maintenance of OnRuby can be supported via Patreon at patreon.com/on_ruby.

Patrons

Installation

You can install OnRuby using Docker or a local installation.

Install using Docker

Get containers

Install Docker and Docker Compose if you haven't already. Then:

docker-compose up --build

sudo might be required for docker-compose if you run Docker locally on Linux.

This creates three Docker containers:

  • web for the application
  • box for storing rubygems installations
  • db for the PostgreSQL database

Prepare the database

In another terminal, run the Rake task to set up the database structure.

script/in_docker bundle exec rake db:setup

The script/in_docker allows you to run commands inside the Docker container.

Example: Running a spec inside the Docker container

script/in_docker bundle exec rspec spec/requests/labels_spec.rb

Add usergroup hostnames to /etc/hosts

Note: This step is currently only necessary for Safari, all other browsers thread localhost as wildcard domain.

Add all supported subdomains to your /etc/hosts file:

127.0.0.1    www.onruby.test hamburg.onruby.localhost cologne.onruby.localhost berlin.onruby.localhost madridrb.onruby.localhost andalucia.onruby.localhost

Visit the site

Navigate to the start page for the OnRuby platform at https://www.onruby.test:3000.

This will list links and logos to all the usergroups.

Install locally

On a Docker Container

docker-compose up postgres -d

./bin/setup
./bin/rails server

On your machine

Install PostgreSQL

# Install PostgreSQL on macOS
brew install postgresql
# or on Ubuntu
sudo apt-get install postgresql postgresql-contrib

# Check if it's running
psql postgres # exit with \q

# Create user and database
createuser -Ps postgres
rake db:setup

Use script/server to run Rails locally, otherwise you need to export the environment options yourself:

bundle --without=production
script/server

Add hosts to /etc/hosts

For working with the whitelabel functionality, you need to add all supported subdomains to your /etc/hosts:

127.0.0.1    www.onruby.test hamburg.onruby.test cologne.onruby.test berlin.onruby.test madridrb.onruby.test andalucia.onruby.test

Access via https://www.onruby.test:3000

Test Data

You don't need any test data to set up a new project!

If you want to have some kind of seed, use this Rake task, to generate some test data:

rake data:create

If you are a Heroku project admin, you can dump Data from Heroku via Taps Gem:

heroku pg:pull HEROKU_POSTGRESQL_MAROON_URL onruby_development

THE GUIDE TO YOUR RUG

These are the steps to get your Ruby Usergroup Site:

  • Fork this repo
  • Run bundle && bundle exec rake fork:usergroup[MyUsergroup]
  • Create a GitHub Pull Request
  • Lean back and wait :)

If you have a custom domain, you need to configure the DNS.

On the admin site we need to:

  • heroku domains:add xyz.onruby.de [custom.de]
  • pull the custom domain into cloudflare
  • create a new GitHub app for that domain and add keys via heroku config:add
  • merge the Pull Request
  • deploy to Heroku
  • add admin privileges to someone for the new RUG

Users Login

In order to register for events, users need to log in first.

The app uses OAuth for that. At this point, it accepts Twitter 1, GitHub and Google as valid OAuth providers.

It also accepts email as a method for registering and logging in, using a custom OAuth provider based on one time passwords (OTP) sent to that email.

When a user is not currently logged in, selecting one of the login providers creates an account for him/her, attaching this provider as a valid auth mechanism.

When a user is already logged in, selecting another provider will add that auth mechanism to the existing user.

Required used information

At this point, the app marks nickname, name and image as required, not allowing a user to be created if any of those are empty. email is not required.

For external OAuth sources, values for those 3 properties are obtained from the providers.

  • When a user is created through them, it gets these (and other) properties from that source.

  • When an existing user adds one of those providers, some of these values are overwritten (name and image), while nickname stays always the same.

For users registered through email OTP, none of these values are available on creation. In order to deal with the validations, they're initialized as follows:

  • nickname is generated by hashing the email address.

  • name is filled in with a known marker for "missing name" declared in User::EMPTY_NAME (currently "********"). It doesn't use the email address as a placeholder in order to avoid exposing it, as the user name is displayed in several pages in the application.

  • image is set to the Gravatar URL for the email.

In order to urge users registered through email to provide a name that can be used in the app, after log in, a user with such an "empty" name is redirected to the profile edit page and asked to provide one.

As with any other source, if such a user later adds another provider, the name and image coming from those will take over the existing ones.

Recovering login for existing users who only had Twitter auth

As a consequence of X deprecating API v1.1, Twitter authentication is not working anymore and registered users that only had defined Twitter as their auth method are left out in the cold.

In order to provide an easy way for these users to access their existing account using another auth provider, the app includes additional logic:

  1. If a new session successfully authenticates using a provider that includes email as part of their info.
  2. If a user (and only one user) already exists with that same email
  3. If that user was using Twitter (and only Twitter) as OAuth provider

If all of these conditions are met, then the new provider is added to the existing user and the login proceeds with that.

If the existing user had other providers already registered, then this logic doesn't kick in, as they can still use one of the others to log in.

As this behaviour could lead to potential account takeovers (if another user had access to an OAuth account with the same email of the original user) there's a deadline after which it will stop working.

The default deadline is the end of year 2024. If needed it can be ajusted by setting the environment variable TWITTER_USER_FALLBACK_DEADLINE to a valid date address string (like '2025-06-30').

Website

OnRuby Website

Admin Interface

The app comes with a Administrate interface to manage the model data.

In order to access the admin stuff, you need to be a registered user with the "admin role".

Typus is mounted under /admin of your label, so it's https://hamburg.onruby.de/admin for Hamburg.

Stuff to manage (CRUD)

  • Users
  • Events
    • Materials
  • Locations and Companies (Companies are just special Locations)
  • Topics (Subjects for activities that users can request or propose)
  • Jobs (These are displayed at top of the page)
  • Highlights (Special information that you want to display for a short period of time)

License

"THE (extended) BEER-WARE LICENSE" (Revision 42.0815): phoet contributed to this project.

As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me some beers in return.

Footnotes

  1. As of 2024 Twitter/X has deprecated API v1.1 and Twitter login is not working anymore