How Should Conditional Paths for Use-case Diagrams be Modeled?

Question

I'm making a website where the visitor can:

• View posts.
• Only use regular or Facebook registration if they're not signed in.
• Only login with Facebook if they've registered with Facebook.
• Only use regular login or password reset if they've registered in the regular way.
• Only create posts or unregister if they're authenticated.

I don't understand how I should model the different use-cases available for the visitor. Since an unregistered visitor can become registered visitor and a registered visitor can become an unregistered visitor, they can do the same thing on the site, they just take different paths.

Are these conditions important for a use-case diagram? Is it too specific to say that regular registration requires many fields to be filled in, while Facebook registration only requires the visitor to choose a username?

Can a use-case extend itself? Like if the registration fails, the visitor repeats the registration again.

Edit: I made a guess how to do the diagram:

Edit 2: Or maybe simpler like this?

Answer 1

As @granier said, Your second model is far better and @Thomas Kilian's points are remakable.

I want to say your mistakes and offer a new Use Case Diagram. I think there are some mistakes in your models (Logically and Practically):

1. Too detailed Use Case Diagram (model 1) (please see my previous post TIPS here)
2. Username is not Use Case.
3. There is not extend relationship between Login and Reset Password. (model 2)
4. Login associated with registered user? All users can trigger Login Use Case (even successful or not).
5. Wrong uses of include and extend and inheritance relationships (model 1).

Please consider my offered Use Case Diagram:

Additionally, you can add pre-conditions and post-conditions to your use case documentation. But, they do not change the Use Cases.