kubaninc / scim_rails

13 Jan, 2025

1 commit

08 Jan, 2025

1 commit

26 Nov, 2024

3 commits

23 Nov, 2024

1 commit

22 Nov, 2024

2 commits

07 Nov, 2024

1 commit

24 Sep, 2024

1 commit

23 Sep, 2024

1 commit

21 May, 2024

4 commits

09 Mar, 2024

2 commits

05 Jan, 2024

4 commits

30 Mar, 2023

1 commit

27 Mar, 2023

3 commits

28 Sep, 2022

1 commit

06 Jul, 2020

1 commit

02 Jul, 2020

2 commits

  • 1930828f   Fix patch endpoint archiving and case sensitivity ... Browse Code » 
    fixes #32

After a fix shipped in #29, you could no longer de-provision a user
because when false was passed in as the value for active, it thought
there was no value for active.

fixes #33

Technically according to the specifications, the value for op is only
valid if it is one of three lower case values. However, our previous
implementation accepted a case insensitive version. Because of this, we
are adding backward compatibility for case insensitivity until we have a
chance to properly make a breaking change and only allow lower case.
    Ross Reinhardt
     
  • a67fa0e6   Remove Gemfile.lock and update Ruby ... Browse Code » 
    The Gemfile.lock is not a file that we want checked in with the gem. The
purpose of a Gemfile.lock is to lock in a combination of dependencies
for an application. In the case of a gem, we are just specifying the
limits for our dependency versions in the gemspec and are not locking in
a combination of dependencies (since ultimately, the application is
in charge of it's own dependencies).

The only effect the Gemfile.lock has in this project is for when running
it in the dummy app; is has no effect on any of the applications it's
installed in. The gem should work against the latest specified in it's
gemspec so there is no reason to pin the dummy app to the version in a
Gemfile.lock checked into source control.

More info in this blog post: https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
    Ross Reinhardt
     

28 Jun, 2020

1 commit

17 Jun, 2020

1 commit

  • 0b5c207f   Fix exception raised when patch endpoint receives invalid request ... Browse Code » 
    fixes lessonly/scim_rails#29

The patch endpoint isn't fully scim compliant yet and only allows for
specific operations. When we received a specific format of request that
wasn't valid, it was raising an exception instead of returning the
expected 422 response.

Add extra validation to prevent this situation when receiving an
unexpected body for a patch request.
    Ross Reinhardt
     

16 Jun, 2020

1 commit

05 Jun, 2020

1 commit

  • fe63c50c   Bump websocket-extensions from 0.1.4 to 0.1.5 ... Browse Code » 
    Bumps [websocket-extensions](https://github.com/faye/websocket-extensions-ruby) from 0.1.4 to 0.1.5.
- [Release notes](https://github.com/faye/websocket-extensions-ruby/releases)
- [Changelog](https://github.com/faye/websocket-extensions-ruby/blob/master/CHANGELOG.md)
- [Commits](https://github.com/faye/websocket-extensions-ruby/compare/0.1.4...0.1.5)

Signed-off-by: dependabot[bot] <support@github.com>
    dependabot[bot]
     

02 Jun, 2020

1 commit

29 May, 2020

2 commits

  • 7ba7da5c   Add ability to supply a callable error handler ... Browse Code » 
    resolves lessonly/scim_rails#23

Why?
The scim engine returns a custom response to the caller in the event
that there is a 500 error in the engine. It rescues any standard error
in order to do this.

Unfortunately this means that when something is broken it does not
bubble up to the parent app's error handling system or even be printed
in the logs.

We cannot just re-raise the exception because you cannot return a
response AND raise an exception as a part of the same request.

To help, this PR will make is possible for you to supply a callable
object that take the exception as it's argument.

If no callable object is provided, we will output the exception to the
logs so that silence is not the default.

To get the old behavior of completely ignoring an exception, you could
supply an empty proc.
    Ross Reinhardt
     
  • b6f156e0   Fix tasks and commands so they can be run from the root directory ... Browse Code » 
    fixes lessonly/scim_rails#25
fixes lessonly/scim_rails#26

Why
Since we are using the spec/ director instead of the default test/ we
need to specify the locations of the dummy application and it's rake
file. With out this, you cannot run things like db:migrate from the root
of the engine as you should. This goes for any rake task you would
usually call from the root. Additionally, commands like rails console
would not work because it would not be able to find the dummy
application to load it.
    Ross Reinhardt
     

26 May, 2020

2 commits

20 Mar, 2020

2 commits