How to convert rsa key to pem using X.509 standard

Question

I'm reading everywhere that if/switch statements are best avoided in most circumstances with OOP. My problem is how to avoid a switch statement when coding a login.

I have an MVP structure and a client when logging in will be redirected to the appropriate view based on the client type which is defined by an enum.

So, if the client is client-type '0' then they should be redirected to the customer home page, if the client-type is '1' then they should be redirected to the admin home page ect...

My first thought is that there should be some client-login classes which are created when a valid username and password are submitted. These classes could each have a specific redirect method - something like customer-login class, admin-login class etc...

The problem now is that my LoginPresenter is the one that calls the redirect methods that belong to the LoginView via the View Interface.

If I was to have my Model return a customer-login class to the Presenter then how could the customer-login class have access to the LoginViews redirect methods?

It seems to me that the Presenter is the only class able to call the redirect methods so I'm a bit baffled how I should proceed. I need some way for the customer-login class to tell the presenter which redirect method to call.

Here is the code as it is now in the Presenter...

    public class LoginPresenter : PresenterBase
{

    private readonly ILoginView _view;

    private readonly ILoginModel _model;

    private ClientType _clientType;

    public LoginPresenter(ILoginView view, ILoginModel model)
    {

        _view = view;

        _model = model;

        _view.LoginAttempt += OnLoginAttempt;

    }

    private void OnLoginAttempt(object sender, EventArgs e)
    {

        AttemptLogin();

    }

    public void AttemptLogin()
    {

        string email = _view.Email;

        string password = _view.Password;


        bool ClientExists = _model.CheckClientExists(email, password);
        if (ClientExists)
        {

            _clientType = (ClientType)_model.GetClientType();

            CheckClientType();

        }
        else
        {

            _view.Message = "Login Failed";

        }

    }

    private void CheckClientType()
    {

        switch (_clientType)
        {

            case ClientType.Customer:
                _view.RedirectToCustomerHomePage();
                break;
            case ClientType.Operator:
                _view.RedirectToOperatorHomePage();
                break;
            case ClientType.Admin:
                _view.RedirectToAdminHomePage();
                break;

        }

    }

Sure, it works with the switch case but it's not a very object oriented approach. Having to ask the model to provide the client-type and then check the client-type feels wrong when I could get the model to give me an object that can tell the presenter itself what it needs - I know im missing something here.

I'd be most grateful for any assistance or advice :D

Solution

From the Azure site itself:

openssl req -x509 -key ~/.ssh/id_rsa -nodes -days 365 -newkey rsa:2048 -out id_rsa.pem

This will convert your private key into a public key that can be used with Azure.

Comments

[Louis Matthijssen]

Are you sure you didn't get any errors using this command? Is your id_rsa.pem empty?

[chris]

It is not empty

[chris]

How would you do your conversion though?

[Louis Matthijssen]

This method is working for me. What are you trying to do with it?

[chris]

Azure only accepts .pem or .cer keys so I can't use my id_rsa key

[Nkosi]

Read up on strategy pattern.

[Chi]

Thanks! Can the strategy pattern handle the problem concerning how to get the redirect called in the view though? That's the major issue for me - the examples I have found so far all have the sub classes calling methods that don't necessarily rely on an external class like a view. The ones I have found are usually to calculate some value or return a string. What could the mechanism be to trigger the correct redirect?

[Nkosi]

You are going to have to provide more code and better explain the scenario in a minimal reproducible example that can be used to represent your problem.

[Chi]

Ok, I will try to describe the problem more clearly - can you let me know what is unclear about the current description so I can try to fill in the gaps?

[Chi]

I have added some more code - hopefully that makes things a little clearer and not more confusing. Put simply I want to get rid of the switch statement if possible. The sole purpose of the switch is to call the correct redirect method. How can I control the call to redirect without using any conditionals to evaluate the client type. It doesn't seem possible to tell the LoginPresenter which redirect to call without some kind of evaluation of the client-type.

[Nkosi]

How familiar are you with SOLID principles? You mention that you are using MVP. From your understanding what is the View's responsibility? Why is it doing the redirect? Based on what you have presented so far, you can have the model return a redirect strategy based on the client. the presenter would then invoke the returned strategy.

[Chi]

I'm using the passive view approach whereby the view is pretty much a slave to the presenter - it contains no logic - mostly just getter and setters - and is instructed by the presenter what to do. The view is the only class which has reference to System.Web resources, thus why I cannot directly call response.redirect from outside the view except with the presenter who can do so via the view interface. Please can you explain what you mean by having the model return a redirect strategy? The model is not aware of the response.redirect call so I'm not sure what it could give to the presenter.

[Chi]

Thank you! I will try to use this first thing tomorrow - it looks likea a great solution. I assume the abstract class and its implementations should exist in the same assembly as the model - with a reference to the assembly that contains the view interfaces?

[Aaron Roberts]

I’m not sure how your project is set up but that sounds like it would work. I don’t exactly think this is the best solution because it created a dependency of your client model on the view, but something like this might be what you end up with.

[Chi]

hmmm, good point - the main purpose of using mvp is to decouple as much as possible. But does the model referencing the view interface cause tight coupling to the view? I was under the impression that it was still considered loose coupling if it was only the interface that was the dependency but perhaps not? Do you feel that the switch statement is actually a preferable solution in this case?

[Aaron Roberts]

It's definitely loose coupling but I'm more concerned about the dependency direction. An object such as Customer or Client I would consider a domain model, and thus would be at the core of an application and should not depend on a layer above it, in this case the view layer

[Chi]

Yes - I agree, I have been striving to keep the dependencies to always point inwards towards the model/core. Perhaps it really would be better to let the swtich statement stand then? Now i'm very confused, on the surface it seemed to satisy Martin Fowlers criteria of being a switch that needed re-factoring since it was a condition based on an enumeration.